CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site

This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Developer Discussion (Moderator: Donald Lobo) »
  • Override / extend civicrm 'entities' (create futureproof plan?)
Pages: [1]

Author Topic: Override / extend civicrm 'entities' (create futureproof plan?)  (Read 336 times)

mallezie

  • I post occasionally
  • **
  • Posts: 33
  • Karma: 0
  • CiviCRM version: 4.5
  • CMS version: Drupal
  • PHP version: 5.4
Override / extend civicrm 'entities' (create futureproof plan?)
May 13, 2015, 07:07:59 am
hi everybody,

I'm working on project for the last weeks where we have a lot of customization request for civicrm-events. We have two 'sorts' of events 'camps' and 'courses'.
Courses are organised by us, and have participant registrations managed by us. While on the other hand 'camps' are organized by our member-organizations and are actually a different use case. In it's base however both are 'events' in the broad sense of the word, so it seems logical to manage both by the CiviEvent entity.

However we need a seperate frontend / search page / fields /  permissions / ... for both events.
At the moment I sort of created subclasses for the forms derived from the 'event' base forms, i gave them seperate paths, and made specific changes in the subclasses. This is quite successfull for most requirements. At the moment i'm sort of stuck on permissions, and as i can see i would need to subclass the BAO_Event class, and i'm a bit scared to do that ;-)

Problem i actually have is that most methods of Event Forms, BAO's and so an aren't very easily extendable in an override method way. I sort of assume that for most 'entities' the situation is sort of the same.

A concrete example to explain myself further.

I have a /manage/camp page extended from manage event, and i would like to have seperate permissions for those page. Suppose i wan't users to access camps, but not events (which are camps and courses). What i can do now, is to create a menu route
<path>civicrm/camps/manage</path>
    <title>Camps</title>
    <page_callback>CRM_Event_Page_ManageCamp</page_callback>
    <access_arguments>access Camps</access_arguments>

Create a subclass and do some customizations
class CRM_Event_Page_ManageCamp extends CRM_Event_Page_ManageEvent {

  /**
   * browse all events
   *
   * @return void
   */
  function browse() {
    parent::browse();
    $rows = $this->get_template_vars('rows');

    //Remove non-camps from result
    $eventType = CRM_Core_OptionGroup::values('event_type');
    foreach ($rows as $key => $event) {
      if (isset($event['event_type_id']) && CRM_Utils_Array::value($event['event_type_id'], $eventType) != 'Camp') {
        unset($rows[$event['id']]);
      }
    }
    $this->assign('rows', $rows);
  }

}


This even allows me to use a specific template and so on.
Now if i would like to change permissions here that my users won't get event permission only my 'camp' permission is would need to change the parent::browse() method instead of extending it.

So i would need to copy the parent method only to change 1 or 2 lines, which is a lot less maintainable off course. The problem is inside the browse method
$permissions = CRM_Event_BAO_Event::checkPermission();
Where i cannot change the permission without copying the entire method.
Another problem is that now i would need a copy of that function since i probabaly couldn't extend it simply from the CRM_Event_BAO_Event class.

What I actually would like to discuss here is to see if we could find a plan to make this better in future civicrm versions. I'm not sure what a good architecture would be to make this better. Probably using interfaces, and seperate in to differen methods and classes could help, perhaps even trying to depend less on static functions could also help. So perhaps designing / freewheeling for an end goal would be good in here.
Otherwise should we also create a plan to get this together in small steps, since rewriting everything at once doesn't sound very feasible to me ;-)

Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Developer Discussion (Moderator: Donald Lobo) »
  • Override / extend civicrm 'entities' (create futureproof plan?)

This forum was archived on 2017-11-26.