Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DSA: Move force-disable button into reviewer action #9330

Closed
wagnerand opened this issue Oct 27, 2023 · 7 comments · Fixed by mozilla/addons-server#21382
Closed

DSA: Move force-disable button into reviewer action #9330

wagnerand opened this issue Oct 27, 2023 · 7 comments · Fixed by mozilla/addons-server#21382
Assignees
Milestone

Comments

@wagnerand
Copy link
Member

wagnerand commented Oct 27, 2023

The existing force-disable button for add-ons needs to be moved into the reviewer actions, so that a reviewer can select a reason and a write a response or use a canned one.
This means that for the force-disable action, the reason and the response are mandatory fields.

┆Issue is synchronized with this Jira Task

@eviljeff eviljeff self-assigned this Nov 1, 2023
@eviljeff
Copy link
Member

eviljeff commented Nov 1, 2023

@wagnerand we should replace the force-enable button too - they're a toggle so makes sense to do the same for the opposite action. I'm assuming we don't want to email developers if we force enable?
... or do we? If so need some details about if comments are mandatory and some guidance on copy.

@wagnerand
Copy link
Member Author

@eviljeff Yes, we should replace the force-enable button as well. I don't believe we need developer communication since that does not do anything to the versions themselves (...unless we start tracking which versions have been disabled during force-disable and then re-enable those with force-enable, this is probably out of scope for this bug though).

Can we make the comment mandatory and just handle it like an internal comment (i.e. don't send it to anyone)? I don't like that it's a bit inconsistent because I suppose we are sending the force-disable comment to the developer, but it's still better than having no documentation at all.

@eviljeff
Copy link
Member

eviljeff commented Nov 1, 2023

re-enable those <versions> with force-enable, this is probably out of scope for this bug though

out of scope for this issue, yeah, but we do need to address that as part of the DSA work (for appeals and overrides)

@eviljeff
Copy link
Member

eviljeff commented Nov 8, 2023

re-enable those with force-enable, this is probably out of scope for this bug though

out of scope for this issue, yeah, but we do need to address that as part of the DSA work (for appeals and overrides)

@wagnerand this landed with #9326 fwiw - now enable and disable are reversible.

@alexandruschek
Copy link

Hello,

I've tested this on stage env and force disable/enable actions work as expected, I've also noticed that the force enable does not appear in add-on history, only in add-on important changes history

image

Thank you!

@eviljeff
Copy link
Member

eviljeff commented Nov 9, 2023

it's because the addon history only shows activity logs linked to a version, and the force_enable activity doesn't have an associated version (the force disable action gets linked to whatever is the current or latest version at the time of the disable). If @wagnerand has opinions on this I can address in a follow-up.

@KevinMind
Copy link
Contributor

@KevinMind KevinMind added repository:addons-server Issue relating to addons-server migration:2024 labels May 4, 2024
@KevinMind KevinMind transferred this issue from mozilla/addons-server May 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants