A listed version block does not set a Disabled status for the blocked version

[AlexandraMoga]

Describe the problem and steps to reproduce it:

1. Add a new block for an add-on with listed versions - see this example
2. Add a min - max version range that will also block at least one listed version
3. Verify the listed version status - in Rev Tools or DevHub - after the block is saved

What happened?

The listed version is Blocked but not Disabled - see here

What did you expect to happen?

The listed version should be disabled automatically when a block is submitted

Anything else we should know?

• unlisted versions are automatically disabled when a block is submitted
• reproduced on -dev and stage

listed version with status 'Approved' after a block was submitted

[eviljeff]

Where is this functionality requested? (Issue/PRD)

[AlexandraMoga]

@eviljeff it wasn't requested in Issues/PRD but, considering that we are setting unlisted versions as disabled when they are blocked, we should probably do the same for listed versions, for consistency.
I had a quick discussion on irc with @wagnerand about this and we concluded that this would be the expected flow.

[eviljeff]

we are setting unlisted versions as disabled when they are blocked

That's not correct. Creating a Block doesn't make any change to the Addon or Versions - listed or unlisted. If you are thinking about #7158 then it's the action in the reviewer tools that disables the version.

[AlexandraMoga]

Yes, you are right about the reviewer tools implication for unlisted. So, to put it more clearly, I was wondering if we could have something similar for listed reviews as well.
For example, when an admin reviewer uses the 'Block add-on' button from More actions section - which means that the block request originates in the reviewer tools - we could automatically disable the versions blocked in the admin. With the current implementation, admin reviewers are required to manually disable those versions afterwards.

I see how my initial request might have some inconvenient consequences in case of an accidental block, but I think it's safe to say that, when the block request originates from rev tools, we can rely on a more detailed analysis of the versions being blocked.

[eviljeff]

@wagnerand / @jvillalobos to opine. #7158 was explicitly about unlisted versions.

[wagnerand]

If feasible, I would appreciate if we could automatically disable all versions that are affected by a block. Otherwise, I will have to do it manually. In every case I can think of, a blocked version would also be disabled.

[eviljeff]

If feasible, I would appreciate if we could automatically disable all versions that are affected by a block. Otherwise, I will have to do it manually. In every case I can think of, a blocked version would also be disabled.

It's not how the Blocklist Admin tool was specified - currently it purposely doesn't touch the Addon/Version/File instances at all. So this would be out of scope for the Blocklist projects and worked on separately/later.

[jvillalobos]

Yeah, the tool didn't contemplate status changes as designed. I can see it being useful to disable the versions once blocked, though it might get confusing if removing a block doesn't revert the status changes (and if we do that, then we would need to somehow store the previous state, etc).

[wagnerand]

@AlexandraMoga, @eviljeff and I are a bit unclear on what this issue asks for. Is it one of the following?

• Add a new action "Block multiple versions" to the reviewer tools page for listed versions
• Disable the versions when you click the "Block add-on" button on the reviewer tools page
• Disable the versions during blocking the add-on in the admin tools (regardless of whether the action originated from the reviewer tools or not)

[AlexandraMoga]

@wagnerand my initial intent was to have what was mentioned in your second point:

• Disable the versions when you click the "Block add-on" button on the reviewer tools page

However, if you have something more practical in mind we can go with that.

[wagnerand]

Following up on this, we should:

Disable the versions during blocking the add-on in the admin tools (regardless of whether the action originated from the reviewer tools or not).

If specific versions or a version range that is not 0-* is blocked, then only the affected versions should be disabled.
If a version range of 0-* is blocked, all versions should be disabled, and the add-on should be disabled as well.

[eviljeff]

If specific versions or a version range that is not 0-* is blocked, then only the affected versions should be disabled.

When should the versions be disabled? When the submission is signed off and the block is created? Or when the submission is created?

Also, it seems like the functionality for #7158 would be redundant as the versions would be disabled as part of the block flow rather than in the reviewer tools.

[wagnerand]

If specific versions or a version range that is not 0-* is blocked, then only the affected versions should be disabled.

When should the versions be disabled? When the submission is signed off and the block is created? Or when the submission is created?

Ideally, when the submission gets signed and the block is created, but we can also do it during submission creation if turns out to be very complicated.

Also, it seems like the functionality for #7158 would be redundant as the versions would be disabled as part of the block flow rather than in the reviewer tools.

Only partly. The block flow in the reviewer tools is available to unlisted versions only.

[wagnerand]

Side note, regardless of channels:

When the block submission gets signed (and the block is created), next to versions being disabled, we should also disable the add-on (set addon.status to STATUS_DISABLED) if the block range is 0-*.

[AlexandraMoga]

I've tested block submissions on -dev and the Disabled status for add-ons and/or versions are applied as follows:

• Add-on is blocked for block range 0-*:
  • both the add-on and its versions are being Disabled - listed example, unlisted example, mixed example
• Add-on is only partially blocked:
  • only the versions included in the block range will be disabled - listed example, unlisted example, mixed example
• Using the Block multiple versions option for unlisted add-ons is still working as before

I'm marking this issue as verified fixed on -dev.