-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Capacities and occupancies for service and program occurrences #117
base: master
Are you sure you want to change the base?
Conversation
2603de9
to
92e6d45
Compare
@Damon-D-Ma The occupancy code requires a waitlist with a queue that has three methods like these:
So the serviceWaitlist will need to have a queue of serviceRegistrations instead of clients. There are four TODOs relating to waitlists in |
Waitlist functions now use a list (queue) of waitslistEntries with a serviceRegistration instead of a client. The ID of the serviceOccurrence is passed in instead of its corresponding waitlist's ID.
For some reason these files didn't want to push.
Nearly identical to that of "serviceWaitlist", however it stores a programOccurrence instead of a serviceOccurrence, and a list of "programWaitlistEntry" instead of a "waitlistEntry". There are two different classes of models for program and service waitlists because it would not make sense to give both a program AND service occurrence to the same model and have one of these values be blank/null depending on which of the two is using it.
@LesterLyu The part relating to service occurrences is complete and partially tested. |
Ready to be reviewed |
No description provided.