Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162590 - owner of duped bug can't edit other bug owned by somebody else
Summary: owner of duped bug can't edit other bug owned by somebody else
Alias: None
Product: Bugzilla
Classification: Community
Component: Bugzilla General
Version: 3.6
Hardware: All
OS: Linux
medium vote
Target Milestone: ---
Assignee: Simon Green
QA Contact: Kevin Baker
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-06 16:37 UTC by Alexandre Oliva
Modified: 2014-12-01 23:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2012-05-10 12:21:28 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2005-07-06 16:37:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
If user X files a bug report x that is later marked as a dupe of bug report y, filed by Y, but user Y walks away from the issue, there's no way for user X to change the status of the bug, by e.g. closing it as solved, providing info requested on NEEDINFO and changing it back to ASSIGNED, etc.  It would be nice if marking a bug as a dupe would not only add the reporter of the dupe as a Cc:, but also grant this reporter edit privileges on the bug.

There are (slight) security implications with this, though.  If I can file a random bug and mark it as a dupe of some bug I couldn't edit before, I can use this to grant myself edit privileges on it.

Also, this doesn't cover the common case of users who, instead of filing dupes, search bugzilla first, and simply add themselves as Cc:.  Granting dupe owners additional privileges that aren't granted to those who help us by not filing dupes doesn't sound like the right set of incentives for good behavior.

It would be nice, anyway, to enable actual and would-be dupe filers to become co-reporters of existing bugs.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.File a new bug
2.Mark it as a dupe of somebody else's bug
3.Try to change the status of somebody else's bug
1.Find a bug you were going to report already in bugzilla
2.Subscribe to it (add Cc:)
3.Try to change its status

Actual Results:  Can't change it

Expected Results:  Ideally, should become co-reporter, and have similar rights as the original reporter

Additional info:

Comment 1 David Lawrence 2008-09-16 16:52:56 UTC
Red Hat Bugzilla is now using version 3.2 of the Bugzilla codebase and therefore this bug will need to be re-verified against the new release. With the updated code this bug may no longer be relevant or may have been fixed in the new code.
Updating bug version to 3.2.

Comment 2 Noura El hawary 2008-12-02 02:21:41 UTC
for the security issues you mentioned we can not really implement this request.

Comment 3 Alexandre Oliva 2008-12-03 05:50:01 UTC
Actually, implementing security checking against privilege escalation, at the time of the dupe, would not only help avoid unintended leaks, but also avoid situations in which a public bug is duped against a restricted one.  Ideally, the dupe should go the other way 'round, or the dupe shouldn't be put in place at all.  IOW, we currently have a potential security problem that ought to be fixed, and so there's no reason to reject a feature that would rely on such a fix to be in place.  I can clone this bug into another for the leak-avoidance feature, if it helps.

Comment 4 Alasdair Kergon 2009-04-24 23:11:57 UTC
I think the original idea is not worthwhile, but we could indeed do with a better solution to dealing with duplicates when the bugs concerned are in different sets of groups - a warning message perhaps explaining who (Cc/Groups) will now get/lose access to what that they didn't before, and making the person doing the action to confirm that is OK before proceeding.

Comment 5 David Lawrence 2010-01-15 17:33:26 UTC
Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and
therefore this feature will need to be implemented against the new release.
Updating bug version to 3.2.

Comment 6 David Lawrence 2010-08-25 21:41:45 UTC
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Bugzilla Development Team

Comment 8 Simon Green 2012-05-10 12:21:28 UTC
I believe what we currently have is sufficient. While the reporter of the duped bug cannot edit the bug details, they (as well as everyone with a RHBZ account) can add comments.

The owner of the bug can then take the appropriate action.

If we were to implement this, it would be a big extension that the Red Hat Bugzilla team would need to carry (since a Bug currently can only have one reporter) and maintain security for.

  -- simon

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