Open Bug 853479 Opened 7 years ago Updated 7 years ago

Adding a local bug to the see-also field creates a backlink in the other bug's see-also field.

Categories

(Bugzilla :: Creating/Changing Bugs, defect, minor)

4.2.5
defect
Not set
minor

Tracking

()

People

(Reporter: philip.chee, Unassigned)

References

Details

After Bugzilla was updated to v4.2 adding a local bug to the see-also field automatically creates a backlink in the other bug back to mine. This led to a add/remove war with the reporter in the other bug who didn't want to be linked to my bug. This is extremely annoying. Also the whole idea of the see-also field was so that people could stop abusing the Blocks/Depends fields. Mandatory creating backlinks thus defeats the raison d'etre.
See Also: → 553932
(In reply to Philip Chee from comment #0)
> After Bugzilla was updated to v4.2 adding a local bug to the see-also field
> automatically creates a backlink in the other bug back to mine. This led to
> a add/remove war with the reporter in the other bug who didn't want to be
> linked to my bug.

Can you provide the bug numbers where this happened so that we can look at a real-life scenario? When the reporter of the other bug removed the see-also from "his" bug, was he aware that as of 4.2, see-also links behave reciprocally, i.e. that he was concurrently going to remove the see-also link from "your" bug, too?
That happens frequently when you want to establish a weak dependency, e.g., from an application-specific bug to a general Core bug. An example is my bug 845353 for SeaMonkey which resulted from bug 818340 and needs to be followed-up upon by any changes coming with bug 851606.

It's of not much interest for the people following bug 818340 that we needed to make follow-up changes in SeaMonkey, thus a reference in a single direction would be appropriate (that was a change in the past which is now followed up upon by the specific application). With bug 851606, it may be a different story as whoever is proposing/making changes there on a short term should be aware if and how this may affect applications to avoid catching them by surprise late in the cycle.

I didn't have a problem with the reporter of either bug, but removed the "See also" dependency for 818340 immediately after seeing that it was bidirectional.

I agree with Phil that both unidirectional and bidirectional relationships should be possible to cover specific cases. Maybe default to creating a counter-link but provide a checkbox when editing that field which one can uncheck to avoid that?
(In reply to Thomas D. from comment #1)
> Can you provide the bug numbers where this happened so that we can look at a
> real-life scenario?

One example I've observer was bug 847546 (SeaMonkey) vs. bug 849460 (Core), which is very similar to the scenario I have encountered.

> When the reporter of the other bug removed the see-also from "his" bug, was he
> aware that as of 4.2, see-also links behave reciprocally [...]?

No discussion past bug 849460 comment #2.
The reporter shouldn't be allowed to edit URLs in the see also field, unless he has editbugs privs.
No longer blocks: 553932
Severity: normal → minor
Depends on: 553932
See Also: 553932
Version: unspecified → 4.2.5
Frédéric, I don't think that's the issue here. Both Phil and myself have editbugs privs, so that's not the problem. My checkbox proposal in comment #2 would simply make the reverse link optional rather than mandatory, thus covering both "see also" aspects.
You need to log in before you can comment on or make changes to this bug.