[Task]: Mark some add-ons as Partner add-ons in the reviewer tools

abyrne-moz commented 2 weeks ago

Description

Any “negative” impact to either the listing or users on either Notable or Partner addons, such as delisting, disabling or blocklist, needs a second checkpoint to ensure additional process is handled prior to the action taking affect. The intention of the checkpoint is to verify communications have been handled, the developer is aware, and we are taking precautions in how end users are impacted.

Until further automated handling of the workflow is available, reviewers will need to notify operations that the checkpoint verification is needed. To do this, the reviewers need to be aware that the addon they are reviewing is Notable and/or Partner related.

Acceptance Criteria

  ### Milestones/checkpoints
  - [ ] A tag of some kind is shown in reviewer tools indicating Notable and Partner status if those are set
  - [ ] Partner status is per-addon [not developer or addon version]
  - [ ] Partner status should not be publicly exposed through any means, API or otherwise
  - [ ] Partner status should appear in reviewer tools independently of any other flags, the partner status should not disappear if other flags, such as promoted flags, are present
  - [ ] AMO does not display partner status via the API
  - [ ] Partner addons may be listed and/or unlisted
  - [ ] Partner status is managed through django admin
  - [ ] List of Partner addons is managed or provided by Business Development
  - [ ] This information should be exposed to Cinder moderators

Checks

[X] If the issue is ready to work on, I have removed the "needs:info" label.
[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 commented 1 week ago

Question that needs to be asked: do we want pre-review on Partner add-ons ? If so, this makes the implementation of that ticket more involved, we would lean towards re-using promoted add-on system in that case.

However to do that, promoted groups would need to be refactored to allow multiple groups/promoted states for a given add-on. But if we were to do that, we would need to determine which one "wins" when there are conflicting rules caused by an add-on having multiple promoted states.

diox commented 5 days ago

Per discussion in standup, it looks like we do want pre-review for partner.

Plan is to:

Have a spike to investigate having multiple promoted groups for an add-on
If that turns out to be easy to do, implement partner add-ons that way with the refactor
If not, we could still implement partner add-ons with the promoted system without refactor but we'd have to do it eventually anyway...

mozilla / addons