Bug 1000524 - Bugzilla should treat missing ID for external tracker as "drop this tracker" when filing/cloning bug
Bugzilla should treat missing ID for external tracker as "drop this tracker" ...
Status: CLOSED WONTFIX
Product: Bugzilla
Classification: Community
Component: Creating/Changing Bugs (Show other bugs)
4.4
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
tools-bugs
: Reopened
Depends On: 909791
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-23 10:57 EDT by Jan Pokorný
Modified: 2013-10-17 07:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-16 15:47:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pokorný 2013-08-23 10:57:18 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.
Comment 3 Simon Green 2013-10-09 23:23:36 EDT
After this bug was filed, we made a change so that you get a Javascript error if one value is specified but the other isn't. I have spoken to the Red Hat Bugzilla product manager, and he agrees that this bug should be marked as WONTFIX.
Comment 4 Jan Pokorný 2013-10-10 06:48:57 EDT
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),
but what's the use case to utilize Javascript error?

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.
Comment 5 Jan Pokorný 2013-10-16 10:03:13 EDT
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?
Comment 6 Simon Green 2013-10-16 15:47:41 EDT
(In reply to Jan Pokorný from comment #5)
> Seriously?

Yes.
Comment 7 Jan Pokorný 2013-10-16 15:57:32 EDT
>> Seriously?
>
> Yes.

Then I am not getting the twist from "Sounds reasonable to me."
to (probably, cannot test retrospectively) >>even more complicated<<.
Comment 8 Simon Green 2013-10-16 20:05:41 EDT
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).
Comment 9 Jan Pokorný 2013-10-17 07:54:26 EDT
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:

- label (as in private javascript data annotation; this is not meant
  to be a dual client-server solution, but could be eventually extended
  to that) reused/already-present external bug fields with a flag denoting
  this fact

- (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.

Note You need to log in before you can comment on or make changes to this bug.