Download buttons for Experimental add-ons are enabled for anonymous users

VERIFIED FIXED in 5.4

Status

P3
minor
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: krupa.mozbugs, Assigned: rdoherty)

Tracking

unspecified
x86
All

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
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
(Reporter)

Updated

9 years ago
Summary: Download buttons for Experimental add-ons is enabled for anonymous users → Download buttons for Experimental add-ons are enabled for anonymous users
Depends on: 498825
Worth investigating but not a new bug so kicking out of 5.0.9.
Target Milestone: 5.0.9 → ---
-> rdoherty.  This situation shouldn't ever occur, right?
Assignee: nobody → rdoherty
Severity: major → minor
Priority: -- → P3
Target Milestone: 5.3 → 5.4
(Assignee)

Comment 4

9 years ago
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?

Updated

9 years ago
Assignee: rdoherty → jorge
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
Attachment #412335 - Flags: review?(clouserw)
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
Attachment #412335 - Attachment is obsolete: true
Attachment #412335 - Flags: review?(clouserw)
Well, it's P3 so I'll just give it to you. :)
Assignee: nobody → rdoherty
(Assignee)

Comment 12

9 years ago
Created attachment 414370 [details] [diff] [review]
v1
Attachment #414370 - Flags: review?(clouserw)
Attachment #414370 - Flags: review?(clouserw) → review+
(Assignee)

Comment 13

9 years ago
r56809
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

9 years ago
verified
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.