Author
Topic: Reimagining Multi-Day Events (Read 591 times)

peter_fcfl

Reimagining Multi-Day Events

August 29, 2016, 01:42:19 pm

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

« Last Edit: August 29, 2016, 02:14:43 pm by peter_fcfl »

JonGold

Ask me questions

Posts: 638

Karma: 81

CiviCRM version: 4.1 to the latest

CMS version: Drupal 6-7, Wordpress 4.0+

PHP version: PHP 5.3-5.5

Re: Reimagining Multi-Day Events

August 29, 2016, 08:44:54 pm

Hi Peter,

I like what you're thinking here, and don't see any particular problems with your implementation. My question is, why contribution pages as the parent? It doesn't really seem like an intuitive match. 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.

Instead, I'd use an entirely new entity (using hook_civicrm_entityTypes). 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.

peter_fcfl

I’m new here

Posts: 3

Karma: 0

Re: Reimagining Multi-Day Events

August 30, 2016, 12:26:56 pm

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.

Quote

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.

Quote

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!

« Last Edit: August 30, 2016, 01:22:04 pm by peter_fcfl »

peter_fcfl

I’m new here

Posts: 3

Karma: 0

Re: Reimagining Multi-Day 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.

I finally found the civicrm_recurring_entity table with all the info I was looking for. I guess that parent_event_id column in civicrm_events is just vestigial?