Limit registration status changes in admin?

[matthijskooijman]

Currently, registration status can simply be edited through the admin. However, when you manually set a registration to REGISTERED, you bypass the waitinglist logic, which might cause the full fields of options to remain unset. You could also accidentally make someone REGISTERED, even when there is no room (though that might be intentional or temporary, so perhaps that should be allowed).

Also, not all state transitions make sense, so maybe some of these should be limited?

This relates to #67.

[matthijskooijman]

This equally applies to changing registration options, since those might also influence the availability of slots or the waitinglist status of the registration.

[ReneB]

Well, "setting a status" is always a bit tricky since none of the application logic applies. I could imagine some kind of state machine logic that could determine "possible states to transfer to" and adding buttons to the form for those states - such as "Register" instead of "Set status to registered", with a possible override option or something. There may still be a requirement for setting the status, but that should be a more explicit action, I think, since it can mess stuff up (and this has happened in the past to our events as well, so it's not an unrealistic scenario).

[matthijskooijman]

WIP comment, out of time for now, will edit to become complete later.

It might be interesting to explore the possible state changes and see which make (no) sense and also what additional work needs to happen. We have the following states:

PREPARATION_IN_PROGRESS
PREPARATION_COMPLETE
REGISTERED
WAITINGLIST
CANCELLED

• From PREPARATION_IN_PROGRESS
  • to PREPARATION_COMPLETE by completing the registration, which is currently not so easy in the admin. Typically, this is something to be done by the user in the frontend anyway.
  • to REGISTERED or WAITINGLIST is probably not meaningful, maybe only allow that through PREPARATION_COMPLETE.
  • to CANCELLED could work when a registration is aborted, but I think we might as well leave it or delete it then.
• From PREPARATION_COMPLETE
  • Back to PREPARATION_IN_PROGRESS does not really make any sense, except maybe when a new option is added (which we probably should not do, but I guess this transition would be allowed and be trivial without requiring other changes).
  • Onward to REGISTERED is the normal flow, which is allowed except when any of the selected options is out of slots, then this should be diverted to WAITINGLIST.
  • Onward to WAITINGLIST would only

... Unfinished

[matthijskooijman]

Before finishing the previous comment, maybe a more interesting angle is thinking about:

• What transitions is a user allowed to do themselves? This is probably a fairly limited set, mostly moving forward.
• What transitions would an organizer need? Which would make sense without risking mistakes or ending up in an invalid situation? These are probably still a limited set of transitions.
• An admin/superuser can probably do arbitrary transitions, though this should probably still observe at least some preconditions.

As for those preconditions, I'm thinking of:

• Updating the full flag of related RegistrationFieldOptions. This should probably happen in all cases.

• Enforcing the number of slots (either by rejecting changes that overflow slots, or moving registrations to the waiting list automatically).

  This seems obvious to also always enforce, including when an admin makes manual changes. However, I can imagine situations where you might (maybe temporarily) want to admit a registration above the number of slots. Maybe when you want to add a slot, but do not want to leave a window between adding the new slot and admitting the registration where a user might register into that new slot. But maybe situations like this should be solved differently?

[matthijskooijman]

One other related issue is that of when to remove medical and address details. In particular, setting the status of a registration to cancelled could mean that these need to be removed. I'm thinking it would be good to make this explicit in the admin (e.g. similar to when you delete an object in the admin, it asks for confirmation showing all the cascaded deletes that will happen), but doing such confirmation is probably easier when status changes are done using admin "actions", rather than just changing the status dropdown directly (though an added complication is that deleting a registration can also cause userdata to be removed, but this is quite hard to model in Django's cascading delete system, especially when deleting multiple objects, since userdata must be delete when the last active registration that needs it is removed. Maybe something with bulk_related_objects could be done, or a fake one_to_one or one_to_many (that's all that django.db.models.deletion.Collector considers) with a custom on_delete handler.