1.2 branch work #29
Comments
|
@wilr @MarcioBarrientos @ajshort @tardinha @stephenmcm @Maldicore @yusuf @sheadawson |
|
We've (NSW Govt) been this module since it was created (mostly on our Intranet, but a few other sites too). I'm currently upgrading our Intranet from 2.4 to 3.1, and I'm using your fork :) Initially, I was a bit worried about your plans above, however, you make a very good case!. Our use is almost entirely for internally facing training sessions, workshops and other similar events. So the current model works well as a single event is created in the site tree, which can contain many sessions (date/time/location). When used with multiple tickets per event (say for beginner or advanced classes), it really fits what we do. Though, having the registrations on the event and not the date time, did always make me wonder, however, we mostly grab the CSV and then filter etc. I think our use is definitely edge, but I just wanted to throw in a real-world example of it working (mostly) well. |
|
@tardinha Thanks for your response. It is good to hear about your uses. So to clarify - you generally use tickets to distinguish between specific sessions that people will attend? I think filtering registrations / attendees is actually always going to be needed no mater which way things are architected. Come to think of it, there are a few ways you could link session times to other parts of the system:
Perhaps you would like to be involved in this part of development? My current intention is to make the module a bit more simple/maintainable moving forward. Another more (lofty) objective for me is to reduce coupling with the event calendar module. I'm glad I put it to the public before jumping in too quickly. I have set up a gitter chat room for this module (my fork) also: https://gitter.im/jedateach/silverstripe-eventmanagement |
|
No worries :) Almost... to clarify with an example...
This works well for us as there's only one SiteTree entry per event, and the blurb is always the same. Any extra details are included on the tickets (which i put on the event page in a little box). While it works, it certainly could be simpler to manage. The only other thing we've done is added a few extra fields to the rego form. I'll be glad to help our wherever possible, though my skillz certainly don't pay the billz :P |
|
We have a similar use-case for a client where they have a single Event object, and multiple DateTimes representing the thing the user actually registers for. The individual DateTimes may differ slightly, but the main 'event' is always the same. eg http://www.mgsm.edu.au/mba-master-of-management-and-postgraduate-programs/information-events/mba-information-session/ The useful thing about this is that the Event URL never changes; from an advertising standpoint, they are always just linking to the top level URL, from which users can select the relevant session to register for. Another way of looking at this though is that in these instances, it might be that they have an 'UmbrellaEvent' type which then has multiple events that users are actually registering for, and inverting the relationship model somewhat. Either way, they're still on 2.4, so they're not necessarily 100% locked into the current data model when moving to 3.1 |
|
@nyeholt Thanks for your feedback. @tardinha @nyeholt Are you in favour of shifting the Registrations relationship to the event itself? I've updated the data model diagram to show how the multiple-date relationship could still be maintained: https://docs.google.com/a/burnbright.net/drawings/d/1zcLgPszK1cCA2fyncwHQyVwPYG5wv76OuuqZOaEEQ_U/edit The registrations list would need to be filtered to extract the attendees for a particular datetime. I've already started work on making these changes, as you can see here: https://github.com/jedateach/silverstripe-eventmanagement/commits/1.2 |
|
From my perspective, the main functionality part is that admin users are able to get the list of people attending a particular date/time - in the use case mentioned earlier, these are subsequently used for creating name tags. Generally speaking I'm okay with moving the registrations - I can see that for the simpler use-cases, the admin process is much simpler, which is an overall positive result. |
|
Agreed. |
|
Something I meant to mention before was the somewhat backwards steps when creating Tickets and DateTimes. Ideally, a user would create a new DateTime, and then create a new associated ticket(s) within that step (as we do now with EventLocation). This would make more sense now that the ticket sale period has changed to a fixed end rather than x days before the session. |
@ajshort Just letting you know that in my fork, I'm starting some work that I'll call '1.2'. Basically in this work I'll be updating the underlying model in a couple of ways:
milestone: https://github.com/jedateach/silverstripe-eventmanagement/milestones/1.2
1.0 diagram: https://docs.google.com/drawings/d/1lolxBDi2WKkxQGQNnhLgcockzlz2sjSn7RmsqGkm0WQ/edit?usp=sharing
1.2 diagram: https://docs.google.com/a/burnbright.net/drawings/d/1zcLgPszK1cCA2fyncwHQyVwPYG5wv76OuuqZOaEEQ_U/edit
In my experience, most clients don't need multiple dates/times per event, although I'm keen to hear if this is not the case in other's experience.
The alternative solution is to create individual registrable events. This is easy enough, because we have all the functionality to create and duplicate the RegistrableEvent page type. Each event can then directly link to many registrations, reducing the need to combine lists of registrations, and mark which date/times are being registered for.
Issues caused by attaching registrations to dates:
The current setup gives the impression we're just nesting events within events. At one point I was thinking you could essentially create one event, and just repeat its occurrences on a regular basis. However, in practice it seems messy, and I've advised clients to just create a new event for different dates.
Continuing to cater for the 'many times/dates/sessions per event' use case.
If you really wanted, each registration attendee could link to one or many date times. This would allow registering for specific days/times/sessions an event offers. The price could be adjusted accordingly. Perhaps event details could even be updated, including adding/removing sessions.
I think this use case is somewhat an edge case, because there is first the assumption that only part of an event will be registered for by some people. So until this functionality is re-introduced, every person is registered for all sessions within an event.
The text was updated successfully, but these errors were encountered: