Cloning a bug fails to copy the assignee over

RESOLVED WONTFIX

Status

()

Bugzilla
Creating/Changing Bugs
--
minor
RESOLVED WONTFIX
13 years ago
3 years ago

People

(Reporter: Wurblzap, Unassigned)

Tracking

Details

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

13 years ago
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

13 years ago
Whiteboard: [Good Intro Bug]

Updated

11 years ago
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0

Comment 1

11 years ago
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

10 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

Comment 3

10 years ago
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

10 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

10 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

9 years ago
Created attachment 355019 [details] [diff] [review]
Setting assign_to to the original bugs assigned_to
Attachment #355019 - Flags: review?(mkanat)

Updated

9 years ago
Attachment #355019 - Flags: review?(mkanat) → review-

Comment 7

9 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

9 years ago
Created attachment 356654 [details] [diff] [review]
checking editbugs, and if cloned_bug
Attachment #355019 - Attachment is obsolete: true
Attachment #356654 - Flags: review?(LpSolit)

Updated

9 years ago
Attachment #356654 - Flags: review?(LpSolit) → review-

Comment 9

9 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

9 years ago
Assignee: create-and-change → nbezzala
Target Milestone: Bugzilla 3.2 → Bugzilla 3.4

Comment 10

9 years ago
Created attachment 377647 [details] [diff] [review]
If cloned bug and haseditbugs privs, set formvalue to original bugs assigned_to
Attachment #356654 - Attachment is obsolete: true
Attachment #377647 - Flags: review?(LpSolit)

Comment 11

9 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

9 years ago
Target Milestone: Bugzilla 3.4 → Bugzilla 3.6

Comment 12

9 years ago
Created attachment 408590 [details] [diff] [review]
used asigned_to->login, moved code to if and else block
Attachment #377647 - Attachment is obsolete: true
Attachment #408590 - Flags: review?(LpSolit)

Updated

9 years ago
Attachment #408590 - Flags: review?(LpSolit) → review-

Comment 13

9 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

9 years ago
Target Milestone: Bugzilla 3.6 → Bugzilla 3.8

Comment 14

6 years ago
Bugzilla 4.0 is restricted to security fixes only.
Target Milestone: Bugzilla 4.0 → ---

Comment 15

6 years ago
Created attachment 628846 [details] [diff] [review]
Add assigned user as CC in cloned Bug

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

6 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

4 years ago
Assignee: nbezzala → create-and-change
Whiteboard: [Good Intro Bug] → [good first bug][lang=perl]

Comment 17

4 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

Updated

4 years ago
See Also: → bug 1005780
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
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Updated

3 years ago
Whiteboard: [good first bug][lang=perl]
You need to log in before you can comment on or make changes to this bug.