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):
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
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.
for the security issues you mentioned we can not really implement this request.
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.
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.
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.
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
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.