Waitlist doesn't automatically change 'waitlist' registrations to 'complete' when slots become available

Same for me. Any news on this issue?

Updated issue summary!

Here is a patch that implements my proposal! I discovered that a new hook isn't necessary or Rules to be notified when a user comes off the waitlist - you can just watch for the entity to update from 'waitlist' to 'complete' - so I removed that bit from the issue summary.

In order to actually work, you need to use a couple other patches to fix other bugs:

#2496559: Event Count not accurately counting active/held states
#2479805: Insufficient Spaces Remaining Text breaks Waitlist

Here's a new version of this patch which fixes a minor bug in hook_entity_delete() which forgot to check the status of the registration being deleted.

This patch is working great for me.

This patch, #4, doesn't have any support for capacity or registration count.

I second to have this functionality integrated into the module. For a large site with lots of registrations it is necassary to automate waitlist functions and I suppose, it is what most user assume the module should do.

Nonetheless it's possible to achieve that with a combination of Rules and VBO (Views Bulk Operations), if you prefer that to patching your module. I'm quite sure it might work with rules only too - it's not like the VBO funcitionalty is needed, but it gives an easy possiblity to expose a result of a view to rules.

1.) Create a View which has as result only the oldest member of the waitlist of a given node, that is the one, who should be promoted to "complete". How to:
-View Type "Registrations".
- Relationship "Registration: Registration to Content"
- contextual filter for the nid of the related content
- filter for State "waitlist"
- sort by registration-id
- Use pager:"Display a specified number of items|1 item".
- Format: Table.
- Fields "Bulk Operations" and "RegistrationID" should be enough.

2.) Create a rule for the event "After deleting a registration"
Condition: Data comparsion [registration:state] is complete
Action 1: Load a list of entity objects from a VBO View. Use your view from step one and give [registration:entity-id] as an argument
Action 2: Set a date value. Set the state of the fetched registration to "complete"

3.) Same way you can set up a rule which reacts on changing the state of a registration from "complete" to "cancelled".

Obviously this could be refined - e.g. check capacity or take into account the slots (we do not need that). Therefore a native solution as part of the modules would be perfect!

I like the idea behind this because normally it's a real time saver but if the event has different types of registrants and some have higher priority in the queue then this becomes a bug. Making this optional would be preferred.

@joelpittet makes a good point, doing this changes a behavior that might be depended on by some. Here's a patch to make it optional, but to start doing it as the default unless you turn it off.

Thanks @mbaynton, that alleviates my concern.

I haven't tested it, but the changes in #10 look good to me!

I'd mark as RTBC, but I wrote the patch in #4, and this went to "Needs review" in #7 because:

This patch, #4, doesn't have any support for capacity or registration count.

I actually don't think this is true? The whole thing is built around capacity and registration count. The code doesn't explicitly look at capacity and count: it's looking for the 'Insufficient spaces remaining.' error to see if the event is at full capacity. Perhaps there was confusion around that? Or maybe I'm not understanding the comment?

I wasn't so sure what that comment meant either; the best guess I had about what might still be lacking along those lines is that it looks like the module supports a notion of a single Registration entity that consumes more than one of the capacity slots. If that was the Registration being deleted, I don't think that number of new Registrations would be promoted, and conversely I think you could promote a Registration that consumed more slots than were actually available.

I'd wager that this feature is rarely used though, and it's easy to examine whether it might be in use through configuration - maximum slots per Registration entity can be configured to 1. Maybe just add a little code to disable autopromotion when multiple slots per Registration are in use, and get this working for the majority?

I just did some manual testing of the latest patch and it seems to work. :-)