Closed Bug 458607 Opened 16 years ago Closed 16 years ago

attachment flag review does not show userlist when usemenuforusers is on

Categories

(Bugzilla :: Attachments & Requests, defect, P4)

3.0.5

Tracking

()

RESOLVED DUPLICATE of bug 339437

People

(Reporter: pzn, Unassigned)

Details

(Whiteboard: [3.0.x only; 3.2 not affected])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.0.3) Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3
Build Identifier: 3.0.5

I added a flag to attachments "review", and when the flag is "?", I should fill in an username in the field Requestee. I switched "on" the parameter "usemenuforusers" and the users list is not shown in this screen.

Reproducible: Always

Steps to Reproduce:
1. Change parameter "usemenuforusers" to "on
2. Create a flag for attachments called "review"
3. Go to a bug, add an attachment of type patch
4. change flag review to "?"

Actual Results:  
The requestee field is a regular text input field

Expected Results:  
The requestee field should be a userlist, to select an username
Version: unspecified → 3.0.5
I cannot reproduce the bug with 3.2rc1 nor with 3.3, only with 3.0.5. I will investigate.
Assignee: ui → attach-and-request
Status: UNCONFIRMED → NEW
Component: User Interface → Attachments & Requests
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Whiteboard: [3.0.x only; 3.2 not affected]
Target Milestone: --- → Bugzilla 3.0
The reason it's working fine on 3.2 and newer is due to bug 339437, which fixed it while implementing a new feature. For 3.0, all we want is the select box, not the new feature itself.
The patch seems pretty invasive. I may decide to not take it for 3.0.6, in which case I will mark this bug as a duplicate of bug 339437, as it's already fixed upstream.
This is almost exactly a dup of bug 339437, isn't it, really? I pretty much think this is a new feature in 3.2.
(In reply to comment #4)
> This is almost exactly a dup of bug 339437, isn't it, really?

Not entirely. As I said in comment 2, the list was added as part of the implementation of a new feature. If we can trivially fix this for 3.0 without implementing the new feature itself, I'm fine with taking it. We are in the grey area here. Note that if this bug remains open long enough, i.e. till 3.2 is released, this bug would automatically be closed as 3.0 would be restricted to security fixes only. ;)
Priority: -- → P4
OK, I don't think the implementation is trivial enough for 3.0, and 3.0 will soon enter in "security fixes only" mode. So we won't fix it for 3.0.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Target Milestone: Bugzilla 3.0 → ---
You need to log in before you can comment on or make changes to this bug.