Closed
Bug 318031
Opened 19 years ago
Closed 10 years ago
Cloning a bug fails to copy the assignee over
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Wurblzap, Unassigned)
References
Details
Attachments
(2 files, 3 obsolete files)
1.65 KB,
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
558 bytes,
patch
|
LpSolit
:
review-
|
Details | Diff | Splinter Review |
If you clone a bug, the fields get pre-filled so that the new bug will be assigned to the default assignee of the target component. I think the assignee of the cloned bug should be specified here by default. This is not (or not only?) because of the JavaScript filling the assignee from the component -- the "value" attribute of the assignee input field is empty. Steps to reproduce: 1) Create a bug, assigned to somebody else than the default assignee 2) Press "Clone this bug" on the new bug 3) Select the same product the original bug belongs to
Updated•19 years ago
|
Whiteboard: [Good Intro Bug]
Updated•17 years ago
|
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0
gah. cloning bugs is totally broken. (and not really fixable) the way it's misused at my office, they intend for bugs to get whichever component's default assignee. a better approach is to offer some way to pick between possibilities.
Comment 2•16 years ago
|
||
(In reply to comment #1) > gah. cloning bugs is totally broken. (and not really fixable) > the way it's misused at my office, they intend for bugs to get whichever > component's default assignee. a better approach is to offer some way to pick > between possibilities. Based on your comments, what is the status of this bug? I'm guessing it was nearly 2 years before your response was added and 8 months until mine was. I see this is of minor severity and probably should be closed. What's your take on this? I vote it's closed and an issue newly opened better pointing to a fixable one. Mike
Please no. The default assignee needs to know about the bug and controls who it is assigned to. Allowing the cloner to choose assignee does not fit with the rest of the system. Think about looking back at the activities, asking the question "When did this bug get assigned to someone other than default assignee?" This bug is a WONTFIX for me.
Reporter | ||
Comment 4•16 years ago
|
||
I agree in case the cloner doesn't have permission to choose the assignee. I disagree if he does -- then he wants to create a clone, an *exact copy* down to all fields.
Comment 5•16 years ago
|
||
The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Comment 6•16 years ago
|
||
Attachment #355019 -
Flags: review?(mkanat)
Updated•16 years ago
|
Attachment #355019 -
Flags: review?(mkanat) → review-
Comment 7•16 years ago
|
||
Comment on attachment 355019 [details] [diff] [review] Setting assign_to to the original bugs assigned_to >-$vars->{'assigned_to'} = formvalue('assigned_to'); >+$vars->{'assigned_to'} = $cloned_bug->assigned_to->email; Obviously incorrect. $cloned_bug is undefined if you aren't cloning a bug, and Bugzilla will crash. Also, as Marc mentioned in comment 4, only users with editbugs privs should be allowed to copy the assignee for the cloned bug. Powerless users should not be allowed to; in this case, the default assignee should be selected (else you could obviously bypass privs checks).
Comment 8•16 years ago
|
||
Attachment #355019 -
Attachment is obsolete: true
Attachment #356654 -
Flags: review?(LpSolit)
Updated•15 years ago
|
Attachment #356654 -
Flags: review?(LpSolit) → review-
Comment 9•15 years ago
|
||
Comment on attachment 356654 [details] [diff] [review] checking editbugs, and if cloned_bug >+ $vars->{'assigned_to'} = $cloned_bug->assigned_to->email if ($has_editbugs); >+} >+ >+if (!$vars->{'assigned_to'}) { >+ $vars->{'assigned_to'} = formvalue('assigned_to'); > } Hum.. this looks wrong to me. If I have editbugs privs, I cannot choose the assignee anymore by passing it to the URL. This is a regression. All you have to do is to pass $cloned_bug->assigned_to->email to formvalue() if the bugs is being cloned and the user has editbugs privs.
Updated•15 years ago
|
Assignee: create-and-change → nbezzala
Target Milestone: Bugzilla 3.2 → Bugzilla 3.4
Comment 10•15 years ago
|
||
Attachment #356654 -
Attachment is obsolete: true
Attachment #377647 -
Flags: review?(LpSolit)
Comment 11•15 years ago
|
||
Comment on attachment 377647 [details] [diff] [review] If cloned bug and haseditbugs privs, set formvalue to original bugs assigned_to >-$vars->{'assigned_to'} = formvalue('assigned_to'); >+if ($cloned_bug_id && $has_editbugs) { >+ $vars->{'assigned_to'} = formvalue('assigned_to', $cloned_bug->assigned_to->email); >+} else { >+ $vars->{'assigned_to'} = formvalue('assigned_to'); >+} Look at other fields. There are two big blocks where they are listed: one for cloned bugs starting at line 406, and the other one starting at line 455. You should move the code there. Also, this code won't work if the 'emailsuffix' parameter is not empty. You want ->login, not ->email. And I partially take back what I said in my previous comment. I just realized that we cannot pass values from the URL when cloning a bug, so we should respect that here too.
Attachment #377647 -
Flags: review?(LpSolit) → review-
Updated•15 years ago
|
Target Milestone: Bugzilla 3.4 → Bugzilla 3.6
Comment 12•15 years ago
|
||
Attachment #377647 -
Attachment is obsolete: true
Attachment #408590 -
Flags: review?(LpSolit)
Updated•15 years ago
|
Attachment #408590 -
Flags: review?(LpSolit) → review-
Comment 13•15 years ago
|
||
Comment on attachment 408590 [details] [diff] [review] used asigned_to->login, moved code to if and else block The patch doesn't apply cleanly. Another checkin must have conflicted with it. Also, please reread my last comment about cloned fields.
Updated•15 years ago
|
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8
Comment 14•12 years ago
|
||
Bugzilla 4.0 is restricted to security fixes only.
Target Milestone: Bugzilla 4.0 → ---
Comment 15•12 years ago
|
||
When cloning a bug, the assignee from the first bug is added in the CC list of the second bug. If the assignee is already in the CC list, it is simply ignored.
Attachment #628846 -
Flags: review?(LpSolit)
Comment 16•12 years ago
|
||
Comment on attachment 628846 [details] [diff] [review] Add assigned user as CC in cloned Bug This patch is unrelated to this bug. You are altering the CC list while this bug is about the assignee field not being set.
Attachment #628846 -
Flags: review?(LpSolit) → review-
Updated•10 years ago
|
Assignee: nbezzala → create-and-change
Updated•10 years ago
|
Whiteboard: [Good Intro Bug] → [good first bug][lang=perl]
Comment 17•10 years ago
|
||
FWIW, I would want this marked as WONTFIX. Just because you are cloning a bug does not mean that the assignee should the assignee of the cloned bug. For example, if I fixed a Bugzilla bug, and glob cloned it for the bugzilla.mozilla.org product (because my code was that good!), then I definitely shouldn't be the default assignee. I have created bug 1005780 to copy these values over to the CC: list however. -- simon
Comment 18•10 years ago
|
||
i agree with simon - just because a bug is cloned doesn't mean it will have the same assignee or qa-contact by default.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Updated•9 years ago
|
Whiteboard: [good first bug][lang=perl]
You need to log in
before you can comment on or make changes to this bug.
Description
•