Appeals on listing content rejections set REQUESTED, rather than creating NHR

[eviljeff]

Fixes: mozilla/addons#16059

Description

Effectively makes appeals work like requesting a new review - setting AddonApprovalsCounter.CONTENT_REVIEW_STATUSES.REQUESTED - and don't set an NHR so it doesn't show up in the normal manual review queue.

Context

We were using CinderAddonHandledByReviewers so it was treating any appeal (or any action) like follow-up from a reviewer tools review, and flagging it for NHR; now we use a different entity class, without that additional code.

I think there are edge cases and additional scenarios that will occur once we start handling content review in Cinder directly, but that piece of work isn't far enough along to know exactly how it will work, so I skipped over that aspect. (In particular, if we allow policies with an action of AMO_REJECT_LISTING_CONTENT to be available in other queues, we'll need to think through how such an appeal should be handled - i.e. should it still be seen as a "content review"? And even if we limit where the policies are available, there is still the possibility of it coming via the t&s escalations queue)

Even without the NHR, appeal jobs on the back of a content review would be available for resolution on the non-content-review review page. There may be edge cases here, so we might want to consider filtering out those appeal jobs.

When I updated the requeue code for 2nd level I realised again that while a decision is held on a AMO_REJECT_LISTING_CONTENT action it will still be in the content review queue, so there isn't really anything extra we can do. (I thought there was already an issue about that bug, but I couldn't find one)

Testing

• Make a listing content review rejection action via the reviewer tools addon content review page
• (check the add-on isn't in the content review queue at this point, nor flagged for NHR in the manual review queue. Clear random NHRs if necessary. If the add-on is promoted, etc, you may need to proceed from the 2nd level approval queue too)
• make an appeal via the link from the email
• see the add-on is in the content review queue, but is not flagged for NHR, so is not in the manual review queue

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[diox]

Given that there is no NHR, I think we should the appeal somewhere more prominently. For a non-content review, the version list will have a NHR displayed in the version list, so it's easy to understand what the reviewer needs to do. Here, there is no indication of an appeal until you select an action and see the checkbox for the appeal job to resolve, so it's quite confusing.

Something like this? (add some conditions in case we don't want the clutter all the time, and tests)

diff --git a/src/olympia/reviewers/templates/reviewers/addon_details_box.html b/src/olympia/reviewers/templates/reviewers/addon_details_box.html
index 9e48ce8e31..aeff4cdfa0 100644
--- a/src/olympia/reviewers/templates/reviewers/addon_details_box.html
+++ b/src/olympia/reviewers/templates/reviewers/addon_details_box.html
@@ -170,8 +170,16 @@
           {% endif %}
           {% if approvals_info %}
             <tr class="last-approval-date">
-              <th> Last Approval Date </th>
-              <td> {{ approvals_info.last_human_review|date }}</td>
+              <th>Last Human Full Approval Date</th>
+              <td>{{ approvals_info.last_human_review|date }}</td>
+            </tr>
+            <tr>
+              <th>Last Human Content Approval Date</th>
+              <td>{{ approvals_info.last_content_review|date }}</td>
+            </tr>
+            <tr>
+              <th>Content review status</th>
+              <td>{{ approvals_info.get_content_review_status_display() }}</td>
             </tr>
           {% endif %}
         </tbody>
diff --git a/src/olympia/reviewers/views.py b/src/olympia/reviewers/views.py
index c87f6f5846..81ba74bf7a 100644
--- a/src/olympia/reviewers/views.py
+++ b/src/olympia/reviewers/views.py
@@ -624,11 +624,7 @@ def review(request, addon, channel=None):
         else []
     )
     approvals_info = None
-    if (
-        channel == amo.CHANNEL_LISTED
-        and addon.current_version
-        and addon.current_version.was_auto_approved
-    ):
+    if channel == amo.CHANNEL_LISTED:
         try:
             approvals_info = addon.addonapprovalscounter
         except AddonApprovalsCounter.DoesNotExist: