addons
addons copied to clipboard
mozilla
Allow add-ons with only unlisted versions to be recommendable too
follow-on from mozilla/addons#6523 - we've got to be careful that non-public add-ons aren't included on the discovery pane regardless of them being recommended. That's what would happen (as far as I can see) if we just relax the queryset in DiscoveryItem.Admin.formfield_for_foreignkey from .public() to .unfiltered()
┆Issue is synchronized with this Jira Task
After discussing with @diox and @EnTeQuAk we're not sure how having unlisted versions be approved would work - either the version would be auto approved as now, which means it would be too late to have a manual review; or the version would not be auto approved - a big change to the assumptions for unlisted versions since their introduction, and significant retooling of the reviewer tools.
(Personally, I'm unclear about the scenario where Mozilla would want to recommend an add-on we won't/can't distribute through AMO.)
We suggest being able to have unlisted versions be recommended should be dropped from this initial release; if there is a need later we can do the work then to support it. @diox to follow-up with Product to get decision.
The question in the PRD is whether we're okay with the API breaking in that case, which is fine with me. We don't expect it to be a common situation, but it's bound to happen.
The API isn't the major problem really - as it stands right now an Add-on needs a current version that is recommendation_approved=True to be is_recommended=True. That doesn't work for unlisted-only add-ons but that's okay because frontend would only display add-ons that are listed anyway.
It's the approval process and the changes needed to devhub & reviewer tools to support ~post~ pre-review for unlisted versions that I expect would be significant.
Alright, let's not do anything for unlisted for now. We might need to in the future, though, probably with more urgency.
We might need to in the future, though, probably with more urgency.
Good job, me! We need this now for the homepage customization project.
Because of what we need in this particular case, we can get away with a partial fix: we can assume that the file being uploaded is already signed by Mozilla, has the Recommended file, and review coordination is happening manually. We would need that:
- [ ] the Recommended XPI upload works
- [ ] the status changes to Recommended on the first upload
- [ ] new listed versions go through the regular Recommended process, with pre-review
- [ ] new unlisted versions with the Mozilla signature won't be altered in any way (regardless of the Recommended file being there or not)
- [ ] new unlisted versions with no signature will be signed as Recommended
@jvillalobos If the special cased add-ons can be signed as recommended outside our flows, do we need the steps listed above? Especially as presumably the links are going to be pointing to a static site?
We strictly don't need this issue to allow add-ons with only unlisted versions to be to included on the hero shelves with an external link. They would just be included without strictly being "recommended" on AMO. (That was my bad to imply it was necessary in mozilla/addons#6813).
If they are signed as recommended elsewhere (off-AMO) then that's good enough for Firefox. And there isn't a need to upload the xpis to AMO when they're unlisted. We'd just need one unlisted version uploaded to create the Addon.
