Bug 162590

Summary:	owner of duped bug can't edit other bug owned by somebody else
Product:	[Community] Bugzilla	Reporter:	Alexandre Oliva <oliva>
Component:	Bugzilla General	Assignee:	Simon Green <sgreen>
Status:	CLOSED WONTFIX	QA Contact:	Kevin Baker <kbaker>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.6	CC:	agk, ebaak, ineilsen, kbaker, sgreen
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-10 12:21:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
Always

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

Thanks
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