Provide a proper way to content-reject a listing

[wagnerand]

(Spun off from https://github.com/mozilla/addons/issues/5430)

The current way of content-rejecting a listing involves rejecting all public versions. This has a couple drawbacks:

1) Most of the issues that warrant a content-reject are unrelated to any submitted version. 2) The author can re-enable their listing themselves without addressing the issues by just submitting a new version. 3) The author has to submit a new version to get their listing re-enabled after they addressed the issues, even though the requested changes were most likely outside of the add-on file (see 1). This also involves bumping the version number and ultimately AMO shipping an update to all users unnecessarily.

Examples of issues that warrant a rejection of the listing and don't require any file modifications: 1) Violations of the Acceptable Use Policy (obscene or pornographic images in screenshots, hate speech in description) 2) Spam

Examples of issues that warrant a rejection but require a new version upload: 1) Mozilla Trademark violation. Usually, this requires a change of the name in the add-on manifest file, and thus a new version submission.

┆Issue is synchronized with this Jira Task

[jvillalobos]

What do you suggest? Disabling the existing files is the most effective way to hide the listing without resorting to yet another disabled state and allowing the developer to make corrections at the same time.

The other way to do this would be to do a global-disable, but that would block the developer from being able to make corrections. I would argue that that is a worse situation than the current one. In cases of serious violations, I think the content reviewers can reject and then escalate so the listing can also be disabled to prevent future submissions bringing it back.

[eviljeff]

with the two examples of a) developers knowingly uploading offensive content and b) spammers spamming, admins should maybe just be disabling the listing rather than rejecting all versions. Either way, do we care about inconveniencing such developers?

[eviljeff]

In the absence of more use cases I'd vote wontfix.

[wagnerand]

Sorry, there are other cases that require an update on the listing:

1) Missing or incomplete privacy policy 2) Some data practises need to be explicitly mentioned in the description. Since this has been a recent addition to our policies, there a quite many add-ons affected by this. 3) Inappropriate screenshots (not necessarily spam/abusive). This is usually when screenshots use the Mozilla trademarks in a non-compliant way.

Maybe @kewisch remembers some more.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.

[kplotnik]

@wagnerand is this story still important? There's no movement since 2020

[wagnerand]

Yes.

[abyrne-moz]

This is becoming a more frequent issue under DSA as AUP violations are now more of a focus.

We also have a reviewer who now is focused on content review and the manual handling of versions is quite cumbersome, or in some cases just not possible because the necessary permissions are only available to reviewers that work on technical add-on reviews.

[abyrne-moz]

Data showing increases in content reviews https://sql.telemetry.mozilla.org/queries/102590#252826

[wagnerand]

The content-review page shows actions to specifically to approve or reject listing content instead of actions that affect versions:

• Approve content: For listings already public, mark the listing as content-reviewed. This has no publicly visible impact. For listings not public yet (initial submission content-review delay), auto-approve the pending version in addition to the above.
• Reject content: Remove the listing page from public visibility, without affecting versions. Listings can either be immediately rejected or rejected with a delay. Email notifications are sent the same as for version rejections.
• Clear pending content rejection: Clears the pending delayed content rejection.

Other already existing actions are:

• Set Needs Human Review
• Reviewer reply
• Force-disable
• Comment

When a rejection is issued, it is shown in the developer hub. After the developer has made the changes that have been requested in the rejection, they can click e.g. a button to request re-review. This will put the listing back into the content-review queue. While the listing is in this state, any pending delayed rejections for that listing should not be executed.

[eviljeff]

if an add-on is content rejected what is the expected flow for a developer to rectify and have their listing page visible again? I.e. do they make the change and then have to press the button to re-request review? (nothing automatic) Where should the button be shown?

[wagnerand]

if an add-on is content rejected what is the expected flow for a developer to rectify and have their listing page visible again? I.e. do they make the change and then have to press the button to re-request review? (nothing automatic) Where should the button be shown?

Yes, nothing automatic, as we do not know how many and which changes exactly need to be made.

I would like @abyrne-moz's input on the devhub UX, but I imagine the "Manage status and versions" page would be a good fit, since it already has a "Listing Visibility" section.

[abyrne-moz]

I started a PRD for this: https://docs.google.com/document/d/1F-SXawnNMCp_K1_JRZdwsniL41tM7kGxo6bbPRX0ZRk/edit