Eventsignup confirmation mails

[hermannsblum]

There was an issue on the admintools that first needs some discussion here:

Kulturis asked for a feature to add additional info to the confirmation mail sent out to users signing up for an event. First question for me: Are there actually emails sent to all users or only to externals?

[NotSpecial]

Yes, the API sends a confirmation mail. While not strictly needed, it is helpful to notify users, as they can be signed up by admins, for example.

[hermannsblum]

Alright, so that would be possible to simply add a textfield for the event that is used as additonal info in the email!

_{Sent with GitHawk}

[NotSpecial]

Yeah, technically that would be no big deal. If there's a need for it from the Kulturteam (and sending separate mails to the participants would not cover the case well), then we should go for it.

[hermannsblum]

All I know so far is „that was a feature that we had before“, not exactly sure about the usecase. Probably some Kulturis can explain us the advantage over a separate email?

_{Sent with GitHawk}

[NotSpecial]

Do you have any particular person at hand, who we could contact?

[cburchert]

I vaguely remember that we discussed this topic at some point. I think we wanted to have a feature to schedule a reminder mail that would automatically be sent e.g. one day before the event and would also be sent instantly to anyone signing up to the event afterwards. This would be useful for stuff like packing instructions for Skiweekend / ESWE / etc that often got missed by people. Given that we have all the tools to send emails and schedule function calls, this actually sounds like a really nice little project for the coding weekend for someone with just a little python experience to work on. It even has cool stages of increasing difficulty: 1. Add a text option to make the confirmation mail customizable. 2. Add a text option that is automatically sent one day before the event. 3. Make this time configurable. 4. Make sure the mail is also sent to people registering late. 5. Allow an arbitrary list of reminders, so you can send increasingly annoying E-Mails every day. We should make sure we get some consensus from the culture people about what we actually need before the weekend. I could imaging that just adding a details view to an event with the packing list might actually be easier than requiring people to wade through their mess of an inbox. Am Mo., 25. März 2019 um 17:10 Uhr schrieb Alexander Dietmüller < [email protected]>:

…

Do you have any particular person at hand, who we could contact? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#362 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACsKUtaILUOIyX41JXk4rVD6-pHvx5Olks5vaPTigaJpZM4cHGsf> .

[NotSpecial]

I agree with your last paragraph: First we need to really define which functionality is needed by the Kulturteam.

[toni-ght]

I just talked to the current Kulturvorstände. We had a special usecase for our event where such a mail would have been nice (we now found another solution), but in the discussion we came to the conclusion that it's not an issue that is not necessary.
we also discussed the automatically sent out reminder. The Kulturis said that on the day of the event, they have a lot of changes in the participant list and have to send out emails manually anyway.

[cburchert]

The Kulturis said that on the day of the event, they have a lot of

changes in the participant list and have to send out emails manually anyway. That is exactly why we discussed the solution that would automatically resend all emails to people signing up after something has been sent already. Am Di., 26. März 2019 um 15:08 Uhr schrieb toni-ght < [email protected]>:

…

I just talked to the current Kulturvorstände. We had a special usecase for our event where such a mail would have been nice (we now found another solution), but in the discussion we came to the conclusion that it's not an issue that is not necessary. we also discussed the automatically sent out reminder. The Kulturis said that on the day of the event, they have a lot of changes in the participant list and have to send out emails manually anyway. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#362 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACsKUvfcD-rbBxURD0dTumf8lZm5GV1Zks5vain4gaJpZM4cHGsf> .

[NotSpecial]

Thank you for your response, @toni-ght .

we came to the conclusion that it's not an issue that is not necessary.

Is the double negative intended? Is the feature necessary or not?

they have a lot of changes in the participant list

This is via the API, or are the changes handled somewhere else?

[toni-ght]

not intended ^^ -> i had a usecase for the issue, but the kulturis had the opinion that it is not necessary in general

they told me that these are the short-term changes which are handled manually in the csv /exel file. at the moment it's handled manually because there is no reason to have a correct participant list in the tool. this would change if we implement the automatically sent out email, that would be a reason to have a correct list in the tool until the event starts

[hermannsblum]

So from this I get that it is actually quite an important feature because without, the api infrastructure is basically not used at the day of the event, and also apps like the checkin app cannot be used?

_{Sent with GitHawk}

[bloryo]

In order to use an checkin app at the day of the event we would need to be able to change the participants lists manually in the admintool (or app), eventhought the "first come, first serve" option is selected in the Admintool. So we would need to to be able to remove people from the participants list, without someone from the waiting list taking the place.
The reason for this is that at the moment we are "kulant" and people who are mailing us e.g. 1 day before the event, saying the cannot attend the event, in most cases do not need to pay, because we find a replacement anyway.
Also, most of the time the registriation is open until 24h before the event. So participants can sign out until then and we can not expect the next person on the waiting list to attend spontaneously the event. We will then first write an email to all the people on the waiting list and fill up the event manually (on the csv table) "first come, first serve". As a last option we ask the people in AMIV and friends who want to come to the event spontaneously and are not on the waiting list.

If changing the participants list manually on the admintool is not possible, I think it would also be possible to keep the participants list on the admin tool up to date on the day of the event, but (in the "last minute scenario" that I explained above) we would need to delete a lot of people from the waiting list... I don't know if that is the right way to do it.

[NotSpecial]

It is already possible to manually accept participants as an admin, even for FCFS, but it seems the admin tools do not support this yet.

Do you think this would be easy to implement, @hermannsblum ?

Additionally, it might be useful to directly add accepted signups as an admin. This is currently not supported (i.e. a signup needs to be created, goes to the waiting list, and can then manually be accepted) -- but I think this should be an easy fix.

However, I have a more fundamental question: Should manual changes to the signups by admins always be allowed, or only after the registration window has closed? (@bloryo , @toni-ght)

[bloryo]

However, I have a more fundamental question: Should manual changes to the signups by admins always be allowed, or only after the registration window has closed? (@bloryo , @toni-ght)

Only after the registration window has closed would be a good idea, i think.

[hermannsblum]

Concerning the admintools I created a description of what is needed, hopefully we implement this soon.

Concerning this issue: I find the title change confusing, we already have manual signup management in the API^^

[NotSpecial]

Not completely, as the management is a bit inconsitent: Admins can PATCH the signup state, but if FCFS is involved, they cannot POST it. But opening a separate issue for this seems like a better idea.

[NotSpecial]

I have moved the management parts of this discussion into separate issues (see above). Let's focus this issue on emails.