Notification for waitlist move up of child registrations

[christophlehmann]

If i register with amountOfRegistrations = 3 and my registration(s) are on waitlist and my registration (first registration) moves up then i get a notification mail. (Ok)

For child registrations i don't get a mail due to their ignoreNotifications=true. Basically ignoreNotifications is nice when one send custom notifications you don't get them multiple times. In case of waitlist move up I'm also interested in getting a notification for child registrations. Not getting a notification for them implies that i need to check the page "my events" from time to time.

My question is how to solve it? I can work on it, but i need a direction for the big picture, if it's okay to solve it in this extension. One can

• simply ignore ignoreNotifications=true in this case (implement sth. like forceNotification=true)
• Add a option for it (I can't imagine a case where one is not interested in that information).

What do you think?

[derhansen]

Good catch. The main intention of the "simultaneous registrations" feature was, that a user could submit multiple registrations for an event by simply using a select box for the amount of registrations in the frontend. Therefore child registrations do not get notified (ignoreNotifications=true), since all registrations have the same email.

When the extensions gets extended e.g. by a custom registration form, where a user can create multiple registrations at once with different email addresses, registrations also gets saved with ignoreNotifications=true. Since this always required customization by a developer, we could add as PSR-14 event in createDependingRegistrations() function, so developers can control all properties of saved child registrations.

Another solution would be to simply set ignoreNotifications=false in moveUpWaitlistRegistrations(), since a user must know, that the registration on the waitlist is now a non-waitlist registration.

So I think the second solution (ignoreNotifications=false in moveUpWaitlistRegistrations() - line 615) would be the way to go. In addition, a child registration should optionally(?) be "detached" from the main registration, because if the main registrant cancels the registration, all child registrations will be cancelled too. Basically the default move up process will make turn child registrations into "standalone" registrations.

I'll take care of required changes and update the documentation about the move up process.

[christophlehmann]

About the detach: The base problem is, lets see it as a group registrations (registration with multiple seeds) is able to split up. The easiest think is to say, all move up or nobody. Real world example: A Klassenfahrt. The teacher should not stay at home because there is one seat missing ;-) Or imagine Eventim. They don't have this problem because they have no waitlist. But the waitlist in general is a nice feature and one won't miss it.

Is there a problem if we clarify that such group registrations can't be split up by the waitlist feature? Group registrants just need to be faster to get the needed amount of seats.

[derhansen]

Then the next problem rises up, since the group registration will nearly never move up (except someone cancels a registration with the exact or greater amount of registrations as the group registration and the group registration must be first on the waitlist).

This topic is not really trivial and requirements depend on customer demands. Therefore I implemented it as a the "Default Move Up Process" with the possibility to completely override it with custom code using a PSR-14 event (see https://docs.typo3.org/p/derhansen/sf_event_mgt/5.2/en-us/ForAdministrators/Waitlist/Index.html)

I want to keep this as simple as possible, since it seems that everyone asking for a move up process has different requirements (e.g. move up by a new priority field, ...).

Since the notification-problem you described is totally valid, I will implement it with ignoreNotifications=false upon the move up process and then add an option to detach the registration from the main registration (default = true) in TypoScript, so cancellation of the main registration will not lead to cancellation of all child registrations in case one of the registrations involved moved up.

[christophlehmann]

Then the next problem rises up...

You are right, one can't make it correct for every case, so KISS might be the here.

Since the notification-problem you described is totally valid, I will implement it with ignoreNotifications=false upon the move up process and then add an option to detach the registration from the main registration (default = true) in TypoScript, so cancellation of the main registration will not lead to cancellation of all child registrations in case one of the registrations involved moved up.

This solution sound pretty good. Thank you!