Allow to regenerate all acceptance/rejection emails

[Rafiot]

Problem you are facing

I accepted the talks, realized I forgot to set the right template. Now, I need to discard all the emails, and change all the talks from accepted to submitted and to accepted again.

Possible Solution

I think there are a few changes that would be very useful:

• multiple select for the submissions to change all of them as accepted/rejected at once
• allowing to regenerate all the acceptance/rejection emails at once

There is an other thing that would be cool:

• saying everywhere the interface says "send" that the mail will be in the send box and not actually send (I wasn't sure it was the default)

Context

User mistake ;)

[rixx]

This is an issue that is well-suited for external contributors – let me know if I can be of any help, either via this issue or via support@pretalx.com.

What this is about

When organisers accept or reject a review, an email to that speaker is generated from the matching template and placed in the outbox. If the template is changed afterwards, the emails will not change, as they have already been rendered with the appropriate variables, and the variables are not retained. There should be a way to regenerated all of the emails available.

How to get started

First of all, leave a comment on this issue to make sure nobody else starts working on this issue at the same time!

Next, you need pretalx running locally on your machine. First, fork the repository to your own GitHub account. Then clone it locally (or set it as your remote if you already cloned it earlier)

Follow the developer setup guide, and then play around with pretalx a bit.
Have a look at the places impacting this issue. Look at the code responsible for the issues (searching for relevant words or files should help you find your way around). We have an explanation of our code structure and the actual data models.

How to do this

We'll need to expand the QueuedMail model to implement this, which is a good idea in any case. You should add a ForeignKey to MailTemplate and to Submission to this model (both optionally) and check MailTemplate.to_mail and QueuedMail.objects.create calls to include this metadata where available.

Now we can:

• Offer to regenerate emails when a template changes
• Offer to regenerate all emails that stem from a chosen template, such as the accept/reject templates

Submit the PR

There are a number of tutorials on the Pull Request workflow online, for example this short version by GitHub itself and this more in-depth tutorial.

Remember to provide documentation and tests, if applicable. Run the tests before opening your PR, including style checks. We have a contribution guide, which ought to prove helpful at this stage.