Frédéric Buclin Reporter
	Description • 20 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.3) Gecko/20040910

I created a new product "B" in my Bugzilla database and moved some bugs to it,
for triage. Unfortunately, flags set in these bugs where not extended to the new
product "B", because the inclusion list was at this time limited to the first
product "A" (or at least, was neither "__All/All__" nor "product B:All"). I
should have been warned about the possible loss of these flags before moving
bugs to the new product "B".

Reproducible: Always
Steps to Reproduce:
1. Create a (bug or attachment) flag for product A
2. Set this flag to "+", "-" or "?" for a bug in this product
3. Move this bug to the (newly created) product B, where this flag does not
apply (product B is not in the inclusion list for this flag)
Actual Results:  
All attachment and bug flags not applicable to product B are lost!

Expected Results:  
A warning should be displayed, like: "You are about to move bugs to a product
where some flags do not apply. If you continue, those flags will be permanently
deleted. If you want to keep these flags and you are sufficiently empowered to
edit flags, please go back and first add your target product to the inclusion
list before moving your bugs. Or click 'Confirm Move' to move these bugs anyway."

The right way to go is to first add product "B" to the inclusion list and then
move bugs to this product. But it would be fine if Bugzilla could warn the user
anyway. Now I have to set flags to all my bugs and attachments again!!!
Fortunately, I can use the Activity Log to retrieve them, but it is a long work
for nothing!

This bug may be due to the resolution of bug 232554.

It should be considered for the trunk as well as the 2.18 branch!

	Frédéric Buclin Reporter
	Comment 1 • 20 years ago

We could also imagine that if the user has "editcomponents" privs, he could have
an option "Add product B to the inclusion list before moving bugs" to
automatically add this product to the inclusion list.

I think something should be done for the 2.18 branch (maybe in 2.18.1 or later).

	Frédéric Buclin Reporter
	Comment 2 • 20 years ago

myk, justdave, do you think this could be included in the 2.18 branch?

	Dave Miller [:justdave]
	Comment 3 • 20 years ago

I'm not going to block 2.18 on this, but I won't stop it from being checked in
on the branch if it winds up not being a risky change (but I have a hard time
imagining that it won't be tricky to fix).  I believe the flags aren't actually
lost, they're just hidden from the UI.  If you were to move the bug back to the
original product, it would probably show up again.  And I *think* there's an
existing bug on this already somewhere (because you can't remove said flags once
it's been moved to the other product, but it still shows up in queries, etc)

	Myk Melez [:myk] [@mykmelez] Assignee
	Comment 4 • 20 years ago

Flags aren't lost, they're removed (and record of their removal is written to
the activity log).  This is as it should be, since the flags are no longer
relevant to the bug once it moves to the new product for which the corresponding
flag types are not enabled.


>The right way to go is to first add product "B" to the inclusion list and then
>move bugs to this product.

If we did this, then anyone with bug editing privileges could add to flag type
inclusion lists, which we don't want.


>But it would be fine if Bugzilla could warn the user anyway.

Most of the time when users move a bug to a new product they want to do so, even
if it means removing no-longer-relevant flags.  If we were to warn them every
time, even though most of the time they'll still choose to move the bug, then we
would be wasting much more of our users time in confirming moves than we
currently waste in making users recreate the flags.


>Now I have to set flags to all my bugs and attachments again!!!  Fortunately,
>I can use the Activity Log to retrieve them, but it is a long work for nothing!

I'm really sorry you had to do this work, and I understand that it feels
unnecessary, but the cost of interrupting many people's moves to prevent a few
such situations from occurring is worse than the cost of making some people
recreate their flags.


>We could also imagine that if the user has "editcomponents" privs, he could 
>have an option "Add product B to the inclusion list before moving bugs"

That's reasonable, but these situations are likely to be so rare on most
Bugzilla installations that I don't think it's worth the additional work and
code complexity to implement this.

The one thing it would be useful to implement (if it doesn't already work like
this) is to migrate flags from one flag type to another on a change in product
if the flag types have the same name.  But that's a different bug.

	Dave Miller [:justdave]
	Comment 5 • 20 years ago

*** Bug 274704 has been marked as a duplicate of this bug. ***

	Frédéric Buclin Reporter
	Comment 6 • 20 years ago

*** Bug 274704 has been marked as a duplicate of this bug. ***

	Frédéric Buclin Reporter
	Comment 7 • 18 years ago

*** Bug 364463 has been marked as a duplicate of this bug. ***