Old Jira Ticket: https://mozilla-hub.atlassian.net/browse/ADDSRV-39

Need scope clarification on "have an option allowing submissions of add-ons matching some criteria (like recommended) to still go through if we so wish."

@wagnerand what do you think about #1830 (comment) ? If it's not needed, it obviously makes our life much easier. If it is, we need the exact criteria/mechanism wanted for bypass (which could be optional, but we still need to know what it is to build it).

I could see an override option for admins to submit a new version for any add-on, in case there is a critical request from a developer (similar to admins being allowed to override a failed validation). I am not sure we should have exceptions for certain sets of add-ons.

@abyrne-moz might want to weigh in on this as well.

Can you provide an example scenario of when we might need to use this? "In case of emergencies" isn't that clear to me, and I assume an emergency lasts a short period of time and therefore limits the need for an override option.

A bypass for admins is trivial for us to implement through a waffle Flag (we'd essentially be adding a Flag that defaults to everyone=True, and when we want to turn submissions off, we'd flip that everyone bit to False, and we could still have superusers left at True to allow admins to submit stuff)

@wagnerand @abyrne-moz

We need copy for this feature. Currently in the PR we have:

• "Submissions have been temporarily disabled. Please check back later". That's the default if no message is set in the waffle Flag.
  On top of that, we have a special error page if somehow the developers bypasses disabled buttons or has unlucky timing and submits an add-on right as the submissions are being disabled. That page has a title and a header:
• "Submissions Unavailable" (page title)
• "Submissions are not currently available" (page header)

I'm thinking "Submissions" is too generic here. Could you help come up with something?

Would "Add-on uploads" be more appropriate?

• "Add-on uploads have been temporarily disabled. Please check back later". That's the default if no message is set in the waffle Flag.
  

On top of that, we have a special error page if somehow the developers bypasses disabled buttons or has unlucky timing and submits an add-on right as the submissions are being disabled. That page has a title and a header:

• "Add-on uploads temporarily disabled" (page title)
  

• "Add-on uploads are temporarily unavailable" (page header)
  

Yeah I think that's good. cc @chrstinalin ^

I did not change anything to the enable-submissions only switched between yes/no/unknown (so I left Superusers checked)

With switch off (no/unknown)

• on dev hub add-on uploads are not available for a regular user or an admin (and I think I should be able to do that as an admin)
• with web-ext I get different results. A first version submitted as a regular user or admin is not possible, I get an error message
  "Service Unavailable". But I can submit new versions (as a developer or admin) which I don't think is expected.

I must continue testing around but I thought I should leave an update so far (I hope I am using the correct settings for the flag)

We don't have the decorator on FileUploadViewSet.create() and we probably should, but that shouldn't be necessary to prevent web-ext submissions, since we still need to use the upload, so we're probably missing it somewhere else ? Need to investigate.

The admin not being able to bypass the flag if superusers is True is also weird.

I'll add my latest test results:

• I tried new addon uploads and new versions from Postman with a regular and then an admin account with "*" permission. Here I hit the 503 every time (I could not make new version uploads with those I tried for web-ext 633391 or 633393)

• from web-ext I could still continue to make new version uploads (I've tested this from AMO dev)
  the addon from the admin account https://reviewers.addons-dev.allizom.org/en-US/reviewers/review-unlisted/633391
  the addon with a regular user https://reviewers.addons-dev.allizom.org/en-US/reviewers/review/633393

• dev hub looks good but I'll mention the theme wizard. If I upload an image the button becomes enabled yet the submission is not going to finish.

• PATCH requests on addon or version endpoints are allowed.

We don't have the decorator on FileUploadViewSet.create() and we probably should, but that shouldn't be necessary to prevent web-ext submissions, since we still need to use the upload, so we're probably missing it somewhere else ? Need to investigate.

I checked the web-ext repo, and it looks like they directly use /addons/upload in the submission process, i.e FileUploadViewSet.create(), which is possibly why it's behaving differently. I did have a decorator on that endpoint originally, but removed it for a reason that's... lost on me now. 🙃

The admin not being able to bypass the flag if superusers is True is also weird.

This I'm stumped on. Does flag_is_active not handle this? I'll look into it some more.

This I'm stumped on. Does flag_is_active not handle this? I'll look into it some more.

Also stumped on this. <flag>.is_active(request) should definitely handle this. There is also a <flag>.is_active_for_user(user) method and when creating a flag with everyone=False and superusers=True it seemed to work fine for me. Maybe some caching involved? Very weird.

Submissions seem to disable correctly for me locally when everyone: None and superusers: True.

on dev hub add-on uploads are not available for a regular user or an admin (and I think I should be able to do that as an admin)

@ioanarusiczki could I ask what the exact steps you took here were?

(Figured it out over Slack -- Everyone was set to No and overrode all other permissions).