-
Notifications
You must be signed in to change notification settings - Fork 8
Queue handling #15
Comments
@willyaranda @stripTM I need some feedback here, I'm not convince about registrations having the 3 status I proposed, because it only applies to registration for events with queue, also confirmed is confusing with the registration confirmed field. Maybe it's better: "queued", "not queued", "place not accepted", "place accepted" And we will need one field more to control date when the place expires. And probably we need more fields on event to control if:
|
Clarification: "We want a queue" is NOT implemented yet. |
I think there are (at least) 5 states for a user:
The queue itself is just sorted by created date. The time to expiration can either be a constant/setting or a field on the event (ah, that is what you suggested with "Queue max time to accept a place"). |
So I've implemented the workflow this way:
Work in progress in the |
Initial implementation done. Pending:
|
Decline ability implemented in 07ced58 |
Email people queued that get a place done in 18da17f Bug there is a bug, if a place is released in the meantime a record is pending confirmation, there is a free place if you register from the site. We need a way to close registrations if max places is reached in any moment and stay closed. |
Bug fixed in c28d6d5 If an event has pending registrations, that means that it shouldn't have freePlaces so is now set to 0. |
Pending: Handle max. answering time via cron or similar and mark as expired. |
https://github.com/jsocol/django-cronjobs for scheduling. We'll need an extra datatime field for registrations to know when the place was released and do the maths. |
Since we are organizing more and more events with limited places, we need a way to handle queues.
So registrations should/could have three status "queued", "not confirmed", "confirmed"
The text was updated successfully, but these errors were encountered: