Red Hat Bugzilla – Bug 1000524
Bugzilla should treat missing ID for external tracker as "drop this tracker" when filing/cloning bug
Last modified: 2013-10-17 07:54:26 EDT
When cloning a bug with an attached external tracker, there is no way
to drop it conveniently in the "Add External Bug" part of the form.
One would expect that by clearing "Bug ID", the respective tracker
will not be added. Which is not the case, rather this is displayed:
> An invalid value '' for an External Bug Tracker Bug ID was submitted.
Personally I prefer minimalism so rather than adding an extra button,
I would like to see the expected principle in effect.
Indeed, one can *also* set the tracker location to "-- do not add --"
(which works), but this would be needlessly cumbersome in case of more
trackers to be removed.
Not a big deal, provided that it's (1 s+) selection of "do not add"
vs (xxx ms+) select field + delete text (in the clone bug usecase,
multiply the action delays by number of trackers already present),
Either you don't fill the text, hence the form submit should
IMHO be, as per the description, a NOOP (or change excluding
the tracker change)/tracker removal (depending on the previous
state) and you can see it was missed in the history changes,
or you fill it.
I am talking mainly about customer portal references that I sometimes
want to drop from a cloned bug as the "cloned" relationships means
something outside the scope of the user cases, etc.
Ah, the current implementation actually goes directly *against* the ease
to drop the tracker as required in this bug.
When cloning a bug ([bug 1014298] to [bug 1019853]), I've tried setting
all the trackers to "do not add" (even though just deleting the IDs from
respective text fields would be easier as stated, but be it), but upon
submit I received complaints probably due to not deleting the respective
IDs *in addition* (the browser got down at that point). Seriously?
(In reply to Jan Pokorný from comment #5)
Then I am not getting the twist from "Sounds reasonable to me."
to (probably, cannot test retrospectively) >>even more complicated<<.
After discussing it with the project manager, we thought it was important to alert people who unintentionally specify one field but not the other (when adding a new external tracker).
It is my belief that this happens much more often than the problem you are trying to solve (removing an external tracker when creating a bug).
Thank for your explanation and sorry for the previous tone.
If I get annoyed enough, I may try to provide a patch along these lines:
to be a dual client-server solution, but could be eventually extended
to that) reused/already-present external bug fields with a flag denoting
- (when either "do not add" chosen as a tracker OR the ID is empty)
AND the annotation implies this is not a newly added external bug,
make the request behave as a valid "drop this tracker" request
Please let me know if something like this would be acceptable at all,
or if I am missing something.