Allow adding, viewing information about and deleting soft-blocks in the admin #22765
Conversation
…he admin Like other blocklist operations, it goes through a BlocklistSubmission, which gains a new "block_type" field to determine what kind of block to apply for this particular submission. Note: If a version is already soft-blocked or hard-blocked, that version won't be selectable when creating a new BlocklistSubmission, even of another type. Future actions will be added to soften or harden blocks.
…h the admin doesn't currently let you do
| @@ -407,7 +409,6 @@ def add_view(self, request, **kwargs): | |||
| 'errors': admin.helpers.AdminErrorList(form, []), | |||
| 'preserved_filters': self.get_preserved_filters(request), | |||
| # extra context we use in our custom template | |||
| 'is_delete': is_delete, | |||
There was a problem hiding this comment.
Was not actually used (blocks.html widget has its own separate context)
diox
requested review from
a team and
KevinMind
and removed request for
a team
What is the rationale for this? If the logic to determine the underlying block type is internalized, why does blocksubmission need a block type at all? |
There was a problem hiding this comment.
If a version is already soft-blocked or hard-blocked, that version won't be selectable when creating a new BlocklistSubmission, even of another type. However, the code underneath should handle overriding the block type for a given blocked version in a submission, and future actions will be added to soften or harden blocks.
Do you know how this would work? Isn't there a concern that to implement that feature will require changes to what you're landing here?
src/olympia/blocklist/migrations/0036_blocklistsubmission_block_type_and_more.py
Outdated
Show resolved
Hide resolved
I'm not entirely sure how hardening/softening actions will work 100%, but the rough plan I've played with is separate explicit actions that allow you to select only relevant blocked versions, similar to how the add/delete actions work. Some tweaks will be required but allowing overrides will help (since ultimately soften/harden are overrides on top of an existing blockversion), even if it's not currently exposed in the admin in this PR. |
The code appears to support Operations making changes to an existing version's hard/soft status, while blocking new versions (so a mix of add and change), but I can't see how the UI in this patch could allow that. If you've got a plan to get there, then that's fine. |
|
Yeah, no UI supporting softening/hardening is in this PR. It's only the small backend bit I've changed that supports the future softening/hardening actions. |
@diox would you mind adding that to the PR? The box is too small for many cases. |
- BlockVersion says Hard/Soft Blocked - BlocklistSubmission says Hard/Soft Block (no "ed")
src/olympia/blocklist/migrations/0037_alter_blockversion_soft.py
Outdated
Show resolved
Hide resolved
Fixes mozilla/addons#15013
Description
Like other blocklist operations, everything goes through a
BlocklistSubmission, which gains a newblock_typefield to determine what kind of block to apply for this particular submission. Users are not allowed to modifyBlocks directly.Note: If a version is already soft-blocked or hard-blocked, that version won't be selectable when creating a new
BlocklistSubmission, even of another type. However, the code underneath should handle overriding the block type for a given blocked version in a submission, and future actions will be added to soften or harden blocks.Testing
Play around with the admin and add/delete
BlocklistSubmission, and then inspect the blocks until you're satisfied. Few things you can try to mix together:BlocklistSubmissionfor add-ons withaverage_daily_usersabovesettings.DUAL_SIGNOFF_AVERAGE_DAILY_USERS_THRESHOLDare subject to approval as before. You can check that it still behaves as expected. You shouldn't be able to modify a block type for a submission you're approving (arbitrary decision on my part, we could change this later)