CiviCRM Community Forums (archive)

I have a Drupal 5 site where CiviEvents are represented in Drupal by a corresponding node, i.e. one event node in Drupal for each CiviEvent record. The synchronization (CRUD) is handled by a custom module. There were several reasons why this approach was taken:

• 1 Calendar integration was easy (i.e. via Drupal nodes)
  
• 2 Text formatting can be done to descriptions with a WYSIWYG editor by non-technical staff members
  
• 3 Images can easily be added to events in Drupal
  
• 4 Event visibility is limited by OG group membership. It is true that the CiviEvents are all actually open to the public, were someone to manually enter the URL, but that's not very common. The Drupal event nodes are the main way visitors interact with the site and those nodes are filtered by OG group membership.

We are now working to upgrade this site to Drupal 6 and the latest CiviCRM. The above issues must be overcome if we are able to leave behind the "dual_event" module and use a pure CiviEvent solution. #1 above is taken care of now with the latest releases of all relevant tools, as is #2 (big thank you to all developers responsible for these innovations!). Item #3 above I think can be handled either as custom fields or by adding IMCE functionality to the rich text editor in CiviCRM (which I would be happy to code if all other issues can be solved). The problem, however, I think is #4.

As far as filtering access to the actual CiviEvent pages by OG group membership, I don't think that can be done natively in CiviCRM, but that should be a fairly simple custom feature to build into a small Drupal module. The other issue is the calendar. If I understand how it works, the Views calendar integration simply makes an SQL query against the CiviCRM database, thus pulling all relevant events. The solution that comes to mind would be to try to use hook_views_query_alter() (or perhaps hook_views_pre_execute) to add on to that SQL the filtering by group membership.

We assign a type to each CiviEvent and I can compare that to the user's OG groups, meaning that if the CiviEvent is of type AAA then only users who are members of the OG group AAA can see it.

So overall, I think this is doable, albeit with all of the filtering being handled by custom code. I think that is preferable to the site's current "dual_event" approach, which has the drawback of data duplication and also will be less useful in the future as CiviEvent functionality becomes more advanced, including repeating events and sub-events etc.

Any thoughts or feedback on the above? It's all still theoretical at this point, but now is the time we need to make a decision which way to go and then proceed with implementation.

Thanks.

Built in ACLs are rather tedious for many events. I used a bit of code like below to restrict access to event registration to a Drupal role called 'members' for CiviEvents of a given event type. You could adapt this to check OG membership pretty easily.

/**
 * Implementation of hook_init().
 */

function civi_access_events_init(){
    global $user;
    if ($_GET['q'] == 'civicrm/event/register' && !user_access('administer CiviCRM') && !in_array('members', $user->roles) ) {
        civicrm_initialize();
        require_once('api/v2/Event.php');
        $event = civicrm_event_get($params = array( 'id' => $_GET['id']) );
        if (in_array($event['event_type_id'], variable_get('civicrm_member_events', array("7")) )) {
          drupal_set_message("You are required to be a logged-in member to register for this event. If your membership is incorrectly unrecognized, please contact the office. You can <a href='/user'>log in here</a>, or you can <a href='/user/register'>register for a website account here</a>.");
          drupal_access_denied();
          exit();
        }
       
      }
}