Email attendees a list of the recorded talks they starred after the event

[Jonty]

Once we reset the website after an event attendees lose the ability to see which talks they starred, which is annoying if you want to go back and watch all the things you didn't see.

Once videos are published it would be nice to email attendees a list of all the talks they starred, with all the ones that were recorded linked + highlighted so they can watch them later.

Bonus nice thing: Attach a file with the ical of the things they starred, just so they have their data.

[jayaddison]

Some initial thoughts on an implementation: perhaps a CLI task that iterates over each login account that has starred events, and for each of those, send an email with a list of hyperlinks to those and then remove the starred-events for that account (a basic method to allow the job to resume without sending multiple duplicate notifications if it fails partway through the process).

[Jonty]

@jayaddison Take a look at how our background email job works for sending emails to all users, this handles recovery https://github.com/emfcamp/Website/blob/888fb8b7d63c7560376bc2d5670b0e46f61fdce0/apps/admin/email.py

We should be able to render the fav list entirely in a template, so all you need to do is enqueue an EmailJob/EmailJobRecipient for every user that has a ticket rendering this new template. https://github.com/emfcamp/Website/blob/888fb8b7d63c7560376bc2d5670b0e46f61fdce0/apps/common/email.py#L136

Ideally we'd like to avoid adding more cli tasks, so it would be nice to have a button somewhere in the interface to fire this off. We probably want to lock it after one run though, unsure what the best way to do that is.

I wouldn't remove the favs from the users purely because we export counts/etc as stats before we nuke the DB, and because people have their personal fav feed set up in ical/etc.

[jayaddison]

Ok; starting (very gradually) on this. Here's what I'm considering so far:

• The feature is a post-event notification email to ticketholders - we're going to send them a message containing a note of the items they'd starred for the event (regardless of actual attendance), and we'll include hyperlinks to video recordings where those are available.
• Since it's a one-time notification per event, before commencing, the code should probably do some basic validation checks (do published recordings exist? what state is the event model in?).
• After the notifications are sent, we don't want to send them again (this could be supported either by a global lock, or a per-ticketholder lock).
• Commencing the notification email could be a feature of the admin portal -- perhaps a button with an accompanying confirmation step (type in "email ticketholders", where x is the number of users who are about to receive the notification email; a statistic to be included elsewhere on the page).
• We can hopefully re-use some of the existing ical support in the website code to provide a calendar-importable attachment with each email.
• Other than any lock/timestamp fields, we shouldn't alter any login account data or records during the process.