Feature idea: Limit for number of participants and waiting list
Hi,
first: if this feature idea should go into an already existing discussion thread or on GitHub as an issue: just let me know (I looked through the documentation and there the discussion page was linked as the place to talk about feature ideas).
I propose that events should have an optional limit for the number of participants (that is the number of people that can be signed up for it). For certain kinds of events that is need either because the venue only provides room for a certain amount of people or the activity can only be run with a set maximum number of people.
With such a feature in place a waiting list for an event might be interesting: when the maximum number of sign ups is reached, new applications go onto the waiting list. If a signed up person cancels the application the first entry from the waiting list gets the now free spot.
What do you think about this feature idea? If you find it valuable I could try to implement it (with the caveat that I'm not very used to PHP) or at least help implementing it.
Kind regards,
Urs
This is indeed a good idea that could be implemented.
Could you write in as much details as possible how this would work? For example, I think it would be nice to allow non group members to attend an event. This needs some logic to verify their email and create a limited user account.
Do you need this as well or am I overthinking it ?
(sent from mobile)
agorakit.org
Allowing non-group member to attend an event wouldn't be necessary. Our group will be a public group, open to anyone for joining.
Here the detailed description for further discussing the feature idea:
For an event there should be an optional maximum number of attendees (that is spots that are available). When all spots are taken new sign ups go onto a waiting list (so people can show that they would be interested in attending in case a spot get freed). The waiting list is ordered by the sign up date. When ever a spot gets freed the oldest entry on the waiting list moves onto the list of attendees and the person that got a spot is notified.
Here is an example flow:
I think the feature could even be implemented in two steps: first only the optional maximum number of attendees. The waiting list could be emulated by manual communication via a discussion in the group. That would not ensure that the oldest waiting list entry gets a spot but as MVP this might be good enough?
I'm also not 100% sure about the domain language (e.g. how the spots on the attendees list and waiting list should be called, just "spot"?) But I haven't look at the existing code. Maybe they become obvious when looking at the existing names.
Simpliest implementation proposal :
Add a setting to the calendar_event table to store max_attendees or something like that.
Then using the attending table, since we know the date of subscription, we can limit the query to show attending people based on max attendees, and a wait list if more than max people are attending, all ordered by date of attending (first come, first served).
If someone unattend, it shortens the list, thus adding the next in queue.
If someone unattend then attend again, he might be put on waiting list if the max attending is full.
This requires little change in the dB, some work in the controller and UI.
Would you be willing to work or help on this?
(sent from mobile)
agorakit.org
Thanks for the directions, Philippe :-).
Yes, I would like to try to implement that on my own.
Currently, I'm struggling a bit with the setup for the dev environment (maybe this is because I'm using podman with the podman-docker compatibility layer on Linux). When I'm following the instructions in https://docs.agorakit.org/localhost.html: do I still have to install a PHP interpreter on my machine or should the dev container image contain everything I need?
My first issue was that after running
there was an error:
running ./bin/dev-connect.sh after that also failed (but I think that is just a logical consequence of the first error) with
The setup in PHPStorm worked after a bit of back and forth (because I didn't read the instruction carefully) but running composer failed because of "unmapped directories". I will investigate further later today or tomorrow.
I don't if you'd be willing to install docker in parallel to podman but I guess it would be the easiest way to start quickly.
None of us are docker nor podman experts : the docker stack was painful to make work, and I expect trying to fix podman support will be equally painful 🙂. I treat docker dev as a common ground, easily trash able and just a useable common ground.
You could of course setup another classic lamp stack, but then you won't have the little goodies Linc added to the docker stack like correct versions of everything.
I hope this won't block your participation. We can (and should) support podman but time is limited...
Help warmly welcome on any fronts !
(sent from mobile)
agorakit.org
Short update: I was able to get the dev setup running using Docker. Won't be able to work on the feature today. Hopefully, tomorrow I will find some time :-).
Great news. I created an issue with ideas and mentionned you here : https://github.com/agorakit/agorakit/issues/700