rsvp urls and notification added

[sahilkashyap64]

Functionality of RSVP

Generate accept and decline url for RSVP

1. Generate ACCEPT and DECLINE url. removalPassword is used to track the user
2. ACCEPT and DECLINE button added in views/emails/addEventAttendee/addEventAttendeeHtml.handlebars

GET url to confirm or decline the RSVP

3. A new route created GET:/event/:eventID/rsvp

Host receives notification

4. Host recieve notification of Accept or decline
5. for notification this template is added views/emails/rsvpNotification/rsvpNotificationHtml.handlebars

For local testing

generate account for SMTP local here https://ethereal.email/
add this in config/config.toml
[nodemailer]
smtp_server = "smtp.ethereal.email"
smtp_port = "587"
smtp_username = ".x@ethereal.email"
smtp_password = "xx"

[halkeye]

So just to be clear, i'm not involved with the project, just contributed some PRs in the past, so my review isn't actually going to change things.

• I like the new rsvpNotification email. Its pretty clear and concise (although the "thanks for using site" at the end isn't really done anywhere else)
• Not sure where the new RSVP requirement comes in as the endpoint that was modified (/attendevent/:eventID) is specifically a user adding themseles to the event, so the flow would be adding themself to the event, to then rsvp that they are coming to the event. It seems a bit confusing flow to me. I feel like the new email just needs to be added to the /attendevent/:eventID endpoint and not the new rsvp feature

[sahilkashyap64]

So just to be clear, i'm not involved with the project, just contributed some PRs in the past, so my review isn't actually going to change things.

• I like the new rsvpNotification email. Its pretty clear and concise (although the "thanks for using site" at the end isn't really done anywhere else)
• Not sure where the new RSVP requirement comes in as the endpoint that was modified (/attendevent/:eventID) is specifically a user adding themseles to the event, so the flow would be adding themself to the event, to then rsvp that they are coming to the event. It seems a bit confusing flow to me. I feel like the new email just needs to be added to the /attendevent/:eventID endpoint and not the new rsvp feature

Admin also adds the attendee sometimes.
Also what if someone adds someone else email.

this is the scenerio i had in mind

1. Admin adds the attendee

   • RSVP required

2. Someone adds someone elses email

   • RSVP required may help

3. people are lazy and won't enter the delete password manually

• The decline button is just 1 click

the notificationRSVP might help host to keep track of user, and maybe host can later catch up with them asking them, was their particular reason for not joing or anything else they may want to communicate

[halkeye]

So there's already https://{{domain}}/event/{{eventID}}/unattend/{{removalPasswordHash}}, so i don't think the new endpoint is needed

As for clicking attending after being added / joinning, thats a pretty big design decision so @lowercasename would have to speak up first but I personally think if an admin adds them, they already know they are attending. It might make sense to have an invite api, which would have the attend/not attend option emailed to them, but thats a different feature and a ticket to talk about it.