Waitlist doesn't respect allow_multiple unless state is active [#2557553]

The registration_waitlist module, in its default configuration, doesn't respect the allow_multiple setting on the registration node.

If you enable waitlist and leave the registration state with its default settings, anyone who registers and is put on the waitlist will be able to register themselves again. This will be confusing. The workaround is to set the waitlist registration state to be "active" on the registration states page. This causes a problem with the event count on the registrations list - it will say there are more slots filled than are available.

To reproduce...
Setup:

On a vanilla Drupal site, download and enable registration, registration_waitlist, and their dependencies.
Create a content type called Event.
Create a registration type. Leave all settings at their defaults.
Add a Registration field to the content type. Leave all field settings at their defaults. (In particular, do not check the "allow multiple" box.)
Set permissions for authenticated users to create, view, and edit registrations. Set permissions for them to register themselves and to register other accounts.
Create an Event node.
In the registration settings for the event node: enable registration, set the capacity to 1, and enable the waitlist. Leave all other settings at the default. (In particular, do not check the "allow multiple" box.)
Create an authenticated user (other than yourself).
Go to the Register tab for the Event. Select "other account" in the "I am registering" field and register the other authenticated user.

The bug:

Go back to the Register tab for the event. You should see the Waitlist message. Choose to register "myself." Save the registration.
You should see success messages about the registration being saved and placed on the waitlist.
Go back to the register tab again.
Note you can still choose "myself" as a registration option.
Choose to register "myself." Save the registration.
Note you see the success messages.
Go to the registrations list for the event.
Note there are two registrations for your account, both with the status of "wait list." You should also see a capacity message that "1 of 1 spaces are filled."

The workaround:

Go to the settings page for Registration States.
Check the box in the Active column for the Wait list status.
Save the settings.
Go back to the register tab for the event.
Note that you no longer have the option to register "myself."
Go to the registrations list for the event.
Note that the capacity message now says "3 of 1 spaces are filled."

Comments

Comment #1

25 August 2015 at 22:35

cboyden created an issue. See original summary.

Comment #2

cboyden CreditAttribution: cboyden commented 25 August 2015 at 22:41

Issue summary:

View changes

Comment #3

cboyden CreditAttribution: cboyden commented 25 August 2015 at 23:02

This is also an issue with any registration state that's not flagged as active. If the user's initial registration is in a non-active state, that user can collect more registrations in non-active states.

Comment #4

dsnopek

he/him

English

USA

CreditAttribution: dsnopek commented 27 August 2015 at 16:53

I'm a little concerned about the workaround of marking the "waitlist" state as active causing other collateral damage. Having a state marked as active is Registration's way of saying that the user is successfully registered for the event, so if something is detecting that (which is not specifically checking for the waitlist state) it could break.

Looking at the code in Registration, it's using 'active' states for the following:

The event count
Who to send the broadcast e-mails to
The result of the registration_is_registered() function, which is in turn used for:
The default field formatter
The 'Allow multiple' support (which is what this workaround is specifically working around)

Some possible alternative solutions:

Adding an API function like registration_can_register() which uses a hook to determine if the user is able to register. By default, this would just check registration_is_registered() and see if multiple registrations are allowed. But the waitlist module could add it's own logic around being on the waitlist. Then this could be used by the field formatter, or anywhere where you want to determine if the user is allowed to register.
Adding a hook to alter the result of registration_is_registered() so that waitlist could directly apply this rules, rather than potentially causing other problems with other uses of the 'active' state (like the broadcast message). However, I think I like #1 first, because the user isn't really registered when they are on the waitlist...

Comment #5

cboyden CreditAttribution: cboyden commented 27 August 2015 at 18:03

Thanks for the suggestions @dsnopek. I also like your idea 1 better. Are you envisioning that registration_can_register() would encompass all of the existing access and capacity checks, or would it just be added as another condition in the existing internal workflow?

Comment #6

dsnopek

he/him

English

USA

CreditAttribution: dsnopek commented 27 August 2015 at 19:40

I'd say it should encompass as much of the checks as it can, unless we end up finding a certain set of checks problematic to include. Someone would need to try to implement it to see if that's the case!