You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Maybe rename Event.Type.REPEATING to STANDARD and Event.Type.STANDALONE to MULTIPART?
This could make it easier to understand that the former is the event type that provides the behavior users normally would expect from creating multiple occurrences (time places), and that the latter is a special case for when an event consists of multiple parts (time places) with a common registration for all of them
If so, should also reword the tooltips for each of the radio buttons in the event form
On the admin page for a specific event:
Make it clearer what event_type an event is (maybe also display this in the event admin list?)
Make it clear to the user what the event_type means for how the event works / should be used; for example:
For a STANDALONE event whose time places are all in the past, show a message equivalent to "Are you sure you know what you are doing?" if a user tries to create more time places for that event - as that likely means that they think it's actually a REPEATING event, or have yet to understand what the event_type of events mean
In the event (change) form:
When a STANDALONE event is changed to REPEATING:
If valid according to the logic below, set the event's number_of_tickets to 0.
If there are no existing tickets connected to the event:
Let the change happen without any further action
If there are existing tickets connected to the event:
If there are no existing time places for the event:
Don't implement, since it's not possible to register for an event with no time places
If there is 1 existing time place for the event:
# Don't use `tickets.update()` instead of this for loop, as we want any signals to be fired normallyforticketin<event>.tickets.all():
ticket.timeplace=<existingtime_place>ticket.event=Noneticket.save()
If there are more than 1 existing time places for the event:
Raise an error saying that this is not possible, and that the user should contact the Dev committee (to potentially come up with a manual workaround - through the Django shell on the server), or create a new (duplicated) event with event_typeREPEATING
When a REPEATING event is changed to STANDALONE:
If valid according to the logic below, and there is one existing time place, set the time place's number_of_tickets to 0.
If there are no existing tickets connected to the event's time places:
Same as for STANDALONE→REPEATING above
If there are existing tickets connected to the event's time places:
If there are no existing time places for the event:
Same as for STANDALONE→REPEATING above
If there is 1 existing time place for the event:
# Don't use `tickets.update()` instead of this for loop, as we want any signals to be fired normallyforticketin<event>.tickets.all():
ticket.event=<event>ticket.timeplace=Noneticket.save()
If there are more than 1 existing time places for the event:
Same as for STANDALONE→REPEATING above, except: [...] create a new (duplicated) event with event_typeSTANDALONE
If the event_type radio buttons are changed (i.e. either one of the above cases), show a message equivalent to "Are you sure you know what you are doing?", which requires the user to submit the form again, or some similar action
In the time place (change) form:
If there exist tickets connected to the time place, and if any of the fields (except number_of_tickets) are changed, show a message equivalent to "There are existing tickets that will have their info changed after this; are you sure you want to do this instead of for example duplicating the occurrence?", which requires the user to submit the form again, or some similar action
(In the past, users have e.g. changed the start_time and end_time fields of a past course to some days into the future, instead of duplicating / creating a new time place for the course, so this change could help prevent that)
The text was updated successfully, but these errors were encountered:
Also prevent admins, because if a standalone event were to be changed to repeating, there would be no time places to transfer the tickets to
(after having implemented the changes mentioned in #563).
* `REPEATING` should be the default choice for most events - even if the event is not planned to repeat,
because if it's decided in the future that another occurrence should be created, that can be done without having to change the type,
and because this event type has the most easily expected behavior for most users.
* `STANDALONE` should only be chosen if the time places need to have one common registration,
which is why this event type has a more detailed description including an example, to make it appear more like a non-standard choice.
This change should also complement the planned renaming of the event types in #563.
Also prevent admins, because if a standalone event were to be changed to repeating, there would be no time places to transfer the tickets to
(after having implemented the changes mentioned in #563).
* `REPEATING` should be the default choice for most events - even if the event is not planned to repeat,
because if it's decided in the future that another occurrence should be created, that can be done without having to change the type,
and because this event type seems to have the most intuitive behavior for most users.
* `STANDALONE` should only be chosen if all the time places need to have one common registration,
which is why this event type has a more detailed description including an example, to make it appear more like a non-standard choice.
Also, the term "multipart" should be more fitting for which kind of event the option is intended to be used for.
These changes should also complement the planned renaming of the event types in #563.
Event.Type.REPEATING
toSTANDARD
andEvent.Type.STANDALONE
toMULTIPART
?On the admin page for a specific event:
event_type
an event is (maybe also display this in the event admin list?)event_type
means for how the event works / should be used; for example:STANDALONE
event whose time places are all in the past, show a message equivalent to "Are you sure you know what you are doing?" if a user tries to create more time places for that event - as that likely means that they think it's actually aREPEATING
event, or have yet to understand what theevent_type
of events meanIn the event (change) form:
STANDALONE
event is changed toREPEATING
:If valid according to the logic below, set the event's
number_of_tickets
to 0.event_type
REPEATING
REPEATING
event is changed toSTANDALONE
:If valid according to the logic below, and there is one existing time place, set the time place's
number_of_tickets
to 0.STANDALONE
→REPEATING
aboveSTANDALONE
→REPEATING
aboveSTANDALONE
→REPEATING
above, except: [...] create a new (duplicated) event withevent_type
STANDALONE
event_type
radio buttons are changed (i.e. either one of the above cases), show a message equivalent to "Are you sure you know what you are doing?", which requires the user to submit the form again, or some similar actionIn the time place (change) form:
number_of_tickets
) are changed, show a message equivalent to "There are existing tickets that will have their info changed after this; are you sure you want to do this instead of for example duplicating the occurrence?", which requires the user to submit the form again, or some similar actionstart_time
andend_time
fields of a past course to some days into the future, instead of duplicating / creating a new time place for the course, so this change could help prevent that)The text was updated successfully, but these errors were encountered: