[Task]: Expand the review queue filters to all possible reasons an add-on can be enqueued

[wagnerand]

trafficstars

Description

As a reviewer or operations person, I want to filter on reasons why an add-on was added to the queue so I can prioritize certain reasons when needed and focus on a set of reviews in times of limited review capacity. I can also dynamically prioritize specific reasons temporarily while larger underlying issues for re-prioritization are addressed that take more time.

Acceptance Criteria

  ### Milestones/checkpoints
  - [ ] The filter list at the top of the queue includes all possible reasons why an add-on can be added to the queue.

Checks

• [X] If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"

┆Issue is synchronized with this Jira Task

[diox]

https://github.com/mozilla/addons/issues/15072 will add a couple of those reasons, but there are more that are grouped together currently.

Essentially this is about expanding needs_human_review_other in Version.get_due_date_reason_q_objects() to each individual possible NHR, and adding a description for each at the end of VIEW_QUEUE_FLAGS in olympia/reviewers/models.py. Bonus point for finding a way to keep everything in sync.

[diox]

As noted in https://github.com/mozilla/addons-server/pull/22900#issuecomment-2506039796 : ideally the form would not use VIEW_QUEUE_FLAGS. That would allow us to stop including needs_human_review_auto_approval_disabled and needs_human_review_promoted in it, which are already displayed through other flags.

Edit: actually (now at least) the form builds the choices from both get_due_date_reason_q_objects() and VIEW_QUEUE_FLAGS ... Those are included because they are in get_due_date_reason_q_objects(), not because of VIEW_QUEUE_FLAGS.

[wagnerand]

As of today, the following reasons are missing and should be added:

• UNKNOWN (can probably be folded into "Other")
• SCANNER_ACTION
• ABUSE_REPORTS_THRESHOLD
• HOTNESS_THRESHOLD
• MANUALLY_SET_BY_REVIEWER
• INHERITANCE

The following are also missing but I am not sure what to do with them:

• PENDING_REJECTION_SOURCES_PROVIDED (quite specific)
• AUTO_APPROVED_PAST_APPROVAL_DELAY (very specific, are we even still using this in practice?)

[diox]

We could consider adding select all/none options as part of this to help with the increase in number of filters.

[wagnerand]

(Expanded the motivation in the description as requested)

[wagnerand]

The following are also missing but I am not sure what to do with them:

PENDING_REJECTION_SOURCES_PROVIDED (quite specific) AUTO_APPROVED_PAST_APPROVAL_DELAY (very specific, are we even still using this in practice?)

Let's add those two as individual reasons as well.

I have an idea about improving the process around provided sources, but that requires some more thinking, a proper definition, and might be a bit more effort than this, so it's beyond the scope of this ticket. But having that category as a filter even temporarily is important enough, especially with the current reviewer workload.

[diox]

On top of the fact that there should now be a filter checkbox for each possible reason for something needing human review (and therefore be in the queue), I've updated the icons a little bit, notably adding one for a scanner hit, growth threshold, abuse reports threshold, and changing the default one.

[ioanarusiczki]

I've looked over dev and stage, my enigma is about what I see in "Was added to a promoted group" and " Belongs to a promoted group"

If I tried with "was added" on dev there's 3 add-ons but they're notable and if I check their review pages the promotion is visible here too "This is a Notable add-on. "

With " Belongs to a promoted group" filter on dev I see all type of promotions , looking at a few they're in awaiting review because of being in a promoted group, so this should be expected.

Stage has this list for "was added in a promoted group". I checked 3 of them and I see the same pattern, they're still considered "Notable" in admin tools but on rev tools pages I don't see the orange promotion banner with "This is a Notable add-on." I've looked at 2246580 or 2245798

Stage with "Belongs to a promoted group" has what I expected to see after making a new recommended and a by firefox addon but there's also other extensions which don't have any badge and looking at review pages they don't seem to be promoted.

I think that's known -> this filter throws 500 errors in Content Review, Pending Rejection and one more queue. It's working for Themes.

[ioanarusiczki]

For themes, I tried for stage new versions on By Firefox themes. This theme is in awaiting review in themes queue with By Firefox badge. With " Belongs to a promoted group" I've no results returned.

[diox]

The difference between the 2 promoted ones:

• "Was added to a promoted group" is for when the add-on is first added to a promoted group, but wasn't originally part of that group when the version was submitted & approved. This is currently only triggered when an add-on crosses the notable threshold.
• "Belongs to a promoted group" is for submissions made for an add-on already part of a promoted group. This is the more common case, affecting all kind of promoted groups that have pre_review (Recommended, Line, Spotlight, Notable).

In addition: if somehow an add-on leaves a promoted group, those flags stay on the version, unless a reviewer reviewed the versions.

[diox]

For themes, I tried for stage new versions on By Firefox themes. This theme is in awaiting review in themes queue with By Firefox badge. With " Belongs to a promoted group" I've no results returned.

mmm yeah, themes are weird and the other condition that causes them to be prereviewed - the fact that they are themes in the first place - takes precedence, and we never flag them for their promoted state. I don't think it's something we care about that much, but worth filing a separate issue for.

[ioanarusiczki]

"Belongs to a promoted group" is for submissions made for an add-on already part of a promoted group. This is the more common case, affecting all kind of promoted groups that have pre_review (Recommended, Line, Spotlight, Notable).

So if I checked dev as I said, it looks alright. Stage is not what I'd expected because most of the extensions don't have a current promotion according to their review page or maybe there's something about Notable add-ons I do not understand. (could be!)

later edit that could be it, were added as notable , if I remember correctly there's a cron - task which runs over them and marks them automatically Notable, unfortunately implementation was a long time ago and they're not too many add-ons that would meet the Notable criteria (to have ADU above a level I think). The cron task may have removed them from notable when it ran.