Bulk Invite from File resets the Invite Forum Mailer customized text

This started happening after I upgraded to v1.9.0.beta5 +30.

When I do a bulk invite from file, I change the Invite Forum Mailer text to be specific for that set of invitations. Then I change it back to a different text for single manual invites. This worked fine until I upgraded to the latest version.

Now what happens is that I change the Invite Forum Mailer and save it, and it looks like it saves ok. But when I actually send an invite it uses the old text, although when I look at the Invite Forum Mailer setting again, it appears to have the new text in it. If I do a bulk invite from file, then it sends out the old text and it resets the text in the Invite Forum Mailer custom text window to the previous version.

Anyone else have this issue or able to reproduce it?

1 Like

I’ve also reproduced the issue on our test site, so it doesn’t appear to be something specific to our particular installation.

@techAPJ maybe have a :eyes:

1 Like

Thanks for taking a look at it!

I am unable to repro this on latest Discourse version.

@Nicholas_Tolstoshev are you seeing any error in /logs?

2 Likes

Thanks for checking! I’ll look at the logs and do some more troubleshooting on my end to see if I can figure out what the problem is.

1 Like

Ok I think I’m making some progress with this. I removed all custom themes and plugins from my test install and the issue is still happening.

What I’ve found is that if you don’t include the variables %{invitee_name} and %{site_domain_name} in the Invite Forum Mailer subject line, then the template will not save properly and will revert to what it was before. If I go to the Text Context tab under Customize, and try to save a change to invite_forum_mailer.subject_template that doesn’t include both of those variables, I get the following error message:
The following interpolation key(s) are missing: “invitee_name, site_domain_name”

So what appears to be happening is that trying to save the Invite Forum Mailer template does a behind the scenes check to make sure those variables are in the subject line and if they aren’t there, the change does not save even though no error message is given.

Steps to reproduce:

  1. Go to Settings->Customize->Email Templates
  2. Select Invite Forum Mailer
  3. Change the Subject to something that doesn’t include the necessary variables. For example just put in “test”
  4. Save Changes
  5. Exit the customization screen
  6. Go back to Settings->Customize->Email Templates
  7. Select Invite Forum Mailer
  8. Note that the Subject changes back to the default of “%{invitee_name} invited you to join %{site_domain_name}”
  9. If you attempt the above steps and make changes to the Subject that keep two required variables, the change will save properly. For example, change the Subject to “%{invitee_name} test %{site_domain_name}” and that change will save properly because the two variables are still in the Subject line.

Can you please try out the above procedure and let me know if you are able to reproduce it @techAPJ?

4 Likes

Also note that this behavior is new to this version. On previous versions of Discourse I was able to save any subject line without it requiring the variables in question.

That is because we validate the field to make sure it has all the required translations / substitutions, which @tgxworld worked on.

1 Like

Validation is good, of course, but wouldn’t a warning / error message be appropriate?

Is the validation new for this version?

It does seem like the code path isn’t checking if the translation was saved successfully at all for email template customizations.

3 Likes

So I’m left with a few questions on this one?

a) Is this expected behavior (and if so can we get an error message)?
b) Why did this start happening on the latest version when it wasn’t before? Is this indeed a new feature? Or was it an old feature that wasn’t working properly and got fixed?
c) Can this be an optional check or a warning, as I’d like to be able to customize the text of the invite fully rather than being constrained to include those variables?

Agreed, I’m adding it to my list.

I’ll see if I can make the validation smarter here

4 Likes

Thank you for looking at this!

I have a PR up for this in

https://github.com/discourse/discourse/pull/5328

that re-enables the invalid interpolation keys check while reverting to the previous behavior where interpolation keys can be left out in customizations.

6 Likes

Merged

https://github.com/discourse/discourse/commit/1c2d1682ae29c36190c959b827d07e162acccffe

The current and correct behavior now is that:

  1. Interpolation keys are allowed to be left out.
  2. Invalid interpolations keys are not allowed.
  3. Custom interpolation keys that we secretly allow are whitelisted in a constant. The whitelist isn’t the best solution I’ve got but I think the invalid interpolation keys is more important to have as it protects users from creating an invalid translation override.
6 Likes

Thanks for taking care of this one!