[Bug]: Correct wording for emails sent with appeals attached after reject or disable

[ioanarusiczki]

What happened?

Followup for #9514

1. An addon is disabled or a version rejected without having a report (it's been decided by reviewers)
2. Developer sends the appeal
3. An email is sent but some changes should be done

What did you expect to happen?

A better choice of words.

Is there an existing issue for this?

• I have searched the existing issues

┆Issue is synchronized with this Jira Task

[eviljeff]

@wagnerand what are your thoughts about this scenario and what the messaging should be?

The scenario is an add-on version is rejected and the developer appeals, but also uploads a new version. If the appeal is resolved with the Approve action on the new version (the intuitive action to take) then the email says the previous decision was incorrect.

[wagnerand]

Good question. It seems like our current workflow is incompatible with this scenario.

[diox]

It's a requirement for the appeal process. @eviljeff had some ideas about workarounds we could add - wouldn't entirely solve the problem but would be good enough to unblock us.

[eviljeff]

The workaround would be adding something to the reviewer tools forms to allow the reviewer to choose exactly how the job should be resolved - so they could choose to both approve a new version and reject the appeal on the old version at the same time. A follow-up for a better experience would be a email template that more accurately explains the appeal become obsolete with the new version approval.

[abyrne-moz]

Can this be resolved by leveraging the new "Comment on AMO Reviewer Tools and Resolve a Cinder escalation" that you're working in @eviljeff ?

[eviljeff]

@abyrne-moz unfortunately not - it leverages a function that currently doesn't result in any action (commenting). It still won't let a reviewer take two different actions (a version approval + an appeal rejection) at the same time.

My suggested workaround from 2 weeks ago was in hindsight a little naive - that a reviewer would even think to reject an appeal to resolve a job while approving a version relies on the reviewer thinking through all the scenarios and knowing what emails are sent. The mental shortcut is still "add-on is good now, appeal is good", imo, so we're leaving a footgun around.

There was an alternative suggestion in one of the triage meetings (alas not documented!) to auto-reject an appeal once a developer uploads a new version that I like.

[abyrne-moz]

To recreate the issue:
- If a decision has been made to take down an add-on version
- Then an appeal is logged
- Then the developer uploads a new version
- That subsequent version is approved
- The reviewer resolves the original appeal

What happens:
- An email is sent to the developer saying that their appeal has been granted, but that might not be true in this case as we’ve made the new decision on the new version, whilst the appeal is against the old one

Potential solution
Improve the wording of the email so that it reflects this possible discrepancy and this resolves the developer communication uncertainty.

"Your appeal has been closed. This is due to either:

1. After reviewing your appeal, we determined that the previous decision was incorrect...
   Or
2. You uploaded a new version, which was approved, therefore we have closed your appeal.

Unfortunately this means we are reporting an incorrect appeal resolution to the transparency report.

@abyrne-moz to check with legal and Trust&Safety to see if we can withdraw an appeal if a new version is uploaded. If so
- Do we need to inform the developer via email?
- Can we inform the developer that this will take place when they go to upload a new version, but there is an appeal outstanding?
- What about submission via the API?