steps to reproduce: 1.Go to https://preview.addons.mozilla.org/en-US/thunderbird/search?q=&cat=all&as=1&vfuz=true&appid=18&lver=any&hver=any&atype=0&pp=20&pid=2&sort=&lup=&show=20&page=35 2.Notice add-ons-Grippies and RegURL observed behavior: Both add-ons look like experimental add-ons ,but have the download button enabled when user is not logged in. screenshot: http://screencast.com/t/YFiWFjEBB8u
Summary: Download buttons for Experimental add-ons is enabled for anonymous users → Download buttons for Experimental add-ons are enabled for anonymous users
Worth investigating but not a new bug so kicking out of 5.0.9.
Target Milestone: 5.0.9 → ---
see also the add-on:"Newsbar" https://preview.addons.mozilla.org/en-US/firefox/browse/type:1/cat:72?show=100&exp=on&only=on&sort=newest&page=2 and the addon-Newsbar https://preview.addons.mozilla.org/en-US/firefox/addon/6072
Target Milestone: --- → 5.3
-> rdoherty. This situation shouldn't ever occur, right?
Assignee: nobody → rdoherty
Severity: major → minor
Priority: -- → P3
Target Milestone: 5.3 → 5.4
I talked with Jorge, this add-on has multiple statuses that are incorrect: http://grab.by/wch Add-on is in sandbox, file is public. This should probably not be allowed by the devcp.
Ah, weird. Jorge: can we sandbox all the public files?
Created attachment 412335 [details] SQL that updates the status for all files causing this bug I ran a query for all add-ons presenting this problem, and there are more than 400 that have sandbox status and at least one public file. There are more than one thousand files to update, so it's better to do it directly on the DB. Wil, can you have a look at this? This should update the status of all public files to "sandbox".
Comment on attachment 412335 [details] SQL that updates the status for all files causing this bug Forgot review flag. BTW, I haven't tested this on Khan yet, and I kinda suck at SQL :P
I don't think we should fix this on the database side. The Dev CP allows this to happen and the Admin CP allows this to happen, so it will keep happening. However, I also don't think we should change the function of those CPs and should instead fix this in the install buttons. In the case in the screenshot, the author of a public add-on moved their add-on from public to the sandbox, as indicated by the highest status field. He can move it back at any time, and the status of the files that have already been reviewed shouldn't be affected.
(In reply to comment #9) > However, I also don't think we should change the function of those CPs and > should instead fix this in the install buttons. In the case in the screenshot, > the author of a public add-on moved their add-on from public to the sandbox, as > indicated by the highest status field. He can move it back at any time, and the > status of the files that have already been reviewed shouldn't be affected. Fligtar is right, this is a UI thing. Thanks for the patch though, Jorge. Ryan, do you have time to look at this before 11/26?
Assignee: jorge → nobody
Well, it's P3 so I'll just give it to you. :)
Assignee: nobody → rdoherty
Created attachment 414370 [details] [diff] [review] v1
Attachment #414370 - Flags: review?(clouserw)
Attachment #414370 - Flags: review?(clouserw) → review+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.