Event registration: moderated modification/removal

[jouvin]

Our Indico instance is used by a University Paris Saclay unit that organized workshops, http://www.institutpascal.uca.fr/index.php/fr/. The program managers manage the event registration to handle the logistics behind (hotel reservations, catering...). At some point, before the event they need to freeze the registrant list and ensure that nobody modifies its registration after they do all the bookings. For this they use the modification deadline.

At the same time, they almost need to handle exceptions after the modification deadlines, particularly these times with the COVID crisis where people tends to change their mind at the last minute. For this they have to reenable the modification (postponing the modification deadline) but due to the number of attendees and the origin variety (around the globe), they have to reopen it for typically one day with the non-negligible risk that somebody else modifies its registration at the same time, with the modification unnoticed.

v3 improved the situation with event log that allows that something was done but this remains not very efficient when managing several programs in parallel, with a large number of registrants. It would be great to have an option to enable a moderated modification (and removal), in the same way as moderated registration.

[ThiefMaster]

Moderated modification? If you mean simply moving back to "pending" (but that'd be a mess if payment is involved), that could be considered - even though I think it's not very common.
If you think an organizer approving the change the user made, I think that's not going to happen. It would add a large amount of complexity, for a use case that is typically handled by "please contact the organizer if you need to make any changes" (who can then modify the registration for the user_...

[jouvin]

@ThiefMaster it is the second case. It's a pitty if you think it will never be considered. Your workaround doesn't scale when you speak about a small organisation that organises many workshops (lasting several weeks each, this is kinds of "hands-on meetings" where people stay together during a long period to work on a topic) and it is in fact quite a significant work to handle it the way you propose. Agreed that it is not the most typical use of Indico but it would be nice if Indico could handle it properly.

[ThiefMaster]

The problem is simply that it's a huge amount of extra complexity - keeping a "pending" version of the registration data, possibly approving only parts of the changes, etc. Not to mention what would happen if the user then tried editing again or a manager changed something in the registration form in the meantime.

Just wondering.. what kind of changes are people making there where you have the need to moderate their changes? Or is this just so you are properly aware of what they changed?

[jouvin]

I understand your points. Certainly it could be as simple (but complex anyway) as keeping the last version of the changes since the last approval until the next one. If the user changes its changes before approval, we certainly don't need to keep track of it. Conflit with a manager change in the meantime is probably more a problem but we could imagine to prevent modification of a registration with pending modification without first approving or rejecting them.

The problem, as I said in the initial description, is all the changes with a financial impact. For example somebody may register for 2 weeks in-person during a six weeks workshop, leading to an hotel reservation by the program manager (it is the way it works with these workshops). For some reasons, 1 week before coming the person changes his/her plans and decide to come only one week. This means that hotel reservation must be adjusted as well as catering to limit/avoid the financial impact for the workshop budget. The price of having a change unnoticed is then relatively high. Is this user story making the use case a little bit clearer?

[ThiefMaster]

Changes with a financial impact - at least when payment on the registrant side is involved - are always disallowed by Indico, since there's no support for making (partial) refunds or extra payments. So if the feature would need to cover something like this as well it'd make things even more complex...

But honestly, I think the example you explained is exactly why events either don't allow this kind of significant changes at all unless it's done early enough (and even then it may be under "no refunds"), and in any case require contacting a human for this...

[jouvin]

I realize that one information is missing. There is no payment involved by the registrants in most cases if I'm right. The unit in charge of organizing these workshops is funded by the university to fund workshop of topics of high interest, so the impact is not on the user but on the program. Clearly if payment was involved, this would make no sense :-)

[ThiefMaster]

OK, this makes it more reasonable :) Would an email notification to organizers listing changes made by the registrant help? I think that would be a much more useful feature and something I could actually see happen in 3.2 (if someone in the team needs a small task before the release something like this is ideal)...

[jouvin]

I think it would be very useful: it would not prevent the modification by at least make it advertized to the persons who need to be aware of it so that they can contact the registrant if necessary. Thanks in advance if it makes it to 3.2!

[ThiefMaster]

Would you mind opening a separate issue for this?

[jouvin]

Done.

[kewisch]

We've come across a similar case, and I would propose a more simple mechanism that could (mostly) cover the initial use case. Similar to how there is a mechanism to grant exceptions for people to submit abstracts, could we do the same for registrations?

There would be a way for event managers to grant people an exception to modify their information, optionally with a deadline until when they could. They can then freely modify their information, without needing to save an extra copy. Once the deadline expires, the modification is disallowed again.

Agree if payment is involved this would no longer be possible.

@jouvin would that work for your case? @ThiefMaster is that something you'd be willing to accept (or maybe even put on the roadmap 🙏 )?

[ThiefMaster]

Being able to grant exceptional modification privileges on a specific registration sounds OK. It wouldn't be ACL-style like in abstracts, but maybe simply a flag on the Registration model whether to always allow modification. PR for this sounds fine to me, I don't think it's something we'd develop ourselves though.

[kewisch]

Sounds good, thank you! Where would you like to see the UI for this? A switch widget within the individual registration that managers can see?

[ThiefMaster]

yes or a toggle button

[kewisch]

How would you feel about a nullable date field so that expiry can be set? In the UI it would be a toggle, and if the toggle is on then a date picker that defaults to 1 week if set. If the toggle is off, the field is null and modification is disallowed. Not sure if we'd go that far yet, but wanted to see if this is something you'd find useful.

[ThiefMaster]

would be OK as well (just trickier UI-wise ;))

[kewisch]

Alright, got it on our roadmap. Someone else from Canonical will do this between now and April :)