[Task]: Create sample ReviewActionReasons in landfill

mozilla / addons

☂ Umbrella repository for Mozilla Addons ✨

Other

127 stars 41 forks source link

[Task]: Create sample ReviewActionReasons in landfill #14930

Open eviljeff opened 3 months ago

eviljeff commented 3 months ago

Description

spun off https://github.com/mozilla/addons/issues/14915

We don't create any ReviewActionReason instances for a fresh local addons-server installation but the reviewer tools isn't usable without at least one RevewActionReason. So lets create some in our landfill app, which generates sample data for initialization.

Acceptance Criteria

  ### Milestones/checkpoints
  - [ ] ReviewActionReasons created in landfill app

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 3 months ago

For most reviewer tools functionality that is going to be enough, but resolving abuse reports with no action (or linking to cinder policies in the admin) would need a cinder policy.

diox commented 3 months ago

Andrew to check whether we can directly import prod in fixtures or something along those lines.

eviljeff commented 3 months ago

Andrew to check whether we can directly import prod in fixtures or something along those lines.

There were no issues raised - other than wanting the data to be up to date (there are some policies in cinder that are different to their associated ReviewActionReason) and a concern about keeping the data aligned long term.

We could reduce the risk here by only importing a subset of the the policies that are fairly stable, so the tools are usable, and anyone is working on cinder<->amo integration can sync the complete set of policies themselves via the admin.

eviljeff commented 3 months ago

The meeting consensus was to add fake CinderPolicy instances via a fixture (or similar) because using real policies with real UUIDs could cause conflicts if the local developer user was to connect to the cinder API.