CiviCRM Community Forums (archive)

I wanted to see what people think of this idea for an extension,  to see if anyone is working on anything similar and/or to get feedback in general.   

It's similar to Multiday Events, except that it's completely in CiviCRM instead of using Drupal dependencies.  Some back story....we'd been considering using the Multiday Events Drupal module for selling courses.  But we need to get that info back out via api....since that data is spread across the CiviCRM and Drupal databases, it's easier said than done. 

The concept is creating a parent object for a number CiviEvents that you can charge for.  The parent object is a Contribution Page.  The sessions are CiviEvents.  (vs. In the old Multiday Events extension, the parent object was a CiviEvent and each session was stored as a Drupal Field Collection. Dude....so un-Civi.  )


What I feel needs is:

• Either custom-data or customdb fields to store an integer of contribution-id  for events.
• A hook into the event config to loop through contribution pages with type=event to produce a radio button list of available contribution pages.
• A hook into the contribution info page to show associated events and also in the contribution config for convenience.   So sessions show up automatically in the Contribution Page.
• A hook into event info pages to override description with contribution page description and also include the  url of the contribution page("Sign up here!")
• A hook into contrib page config  (or just a post hook would do it maybe) to transfer 'enabled' state to corresponding event pages.  So that everything stays in sync...Contribution Pages and associated CiviEvents.

Thoughts?

Thanks,
Peter

Thanks Jon!  In terms of why the contribution page as parent, it was the closest thing that resembles a product, which is how we had been thinking about the courses.  It has the payment parts we need (especially online) and also integration with cividiscount.  Plus it has "Financial Type" = "Event Fee", so it's not totally insane.  :-)

I think you'd also quickly clutter your contribution page screen - most orgs I work with have 1-10 contribution pages, but would have far more multiday events.

Thanks, I hadn't considered that. You're right, it could get messy.....unless we disassociate old children for new ones constantly, which might make it difficult to keep track of changes we make along the way, or do reporting. 

Seems like it might be possible to hook into the manage-contribution-pages page to hide the "expired" ones.  Then if you hit the search button, they all appear.   Like the way events work. 

Instead, I'd use an entirely new entity (using hook_civicrm_entityTypes).

Cool, I didn't know about creating entities!  But if I went that route, wouldn't I have to replicate all the functionality I would get from contribution pages?     Sorry, I'm not following how an implementation would work using a new entity type.

Either that, or use a "master" event.  I've faked something similar with repeating events, since the schema's already in place; change the first event, and you have the option of changing all events.

That's a good idea, but I'm not sure it would work for our needs.  Via api, we'd need to associate the 'master' with the child events.   Using api-event-get, to return the parent_event_id seems to only return the price_set_id (maybe a bug?)   Strangely, even though we use repeating events, the entire column for parent_event_id is NULL.  So I'm mystified as to where the repeating info is stored in the DB. We'd have to differentiate courses from regular repeating events in that scenario.

Using the 'master' event might do the job, but with some careful planning... we'd have to turn off online registration initially when creating the event set and the set only the first in the series to take payment.  That way people wouldn't be able to register for child events.

If the propagation of changes to child events was predictable(not sure), and if the repeating event info was accessible via api, we might just need a simple boolean to differentiate the courses from regular repeating events. 


Thanks for thinking about this!