At our site we need to be able to limit who can verify or close a bug. (QA and Release Engineering). Attached will be (as soon as the bug is commited and I can push the button) is a patch that added two new params, two new privlage groups and code to use them. The default is not to limit who can close or verify so as not to break other sites. The test for verify and close is done in process_bug.cgi befor other user type checks because we needed this to limit users even if they have the "editbugs" privlage. In addition this patch containes one new file. mktar which is a very simple script to make a tar file (we have two servers and I like some release control on my production system). As soon as I have the attachment set I will announce this on the news group.

eta on getting a review and [if okay] checkin on this?

moving to real milestones...

*** Bug 31738 has been marked as a duplicate of this bug. ***

hmmm... I really like this idea, but the though of adding more system groups makes me nervous at this point, because I already know of several installations that have maxxed out their groupsets with product groups. I think we need to resolve the limitations on the number of available groups first...

This patch looks a bit stale and I really like the idea, but this doesn't meet the security criteria for 2.14 and it also takes 2 more groups away. Should this be bumped to 2.16?

ditto on zach and dave. we really need to fix the groups code as well. moving to 2.16

-> Bugzilla product, Changing Bugs component, reassigning.

I think the ability to control who can VERIFY or CLOSE bug is quite useful indeed. I am evaluating Bugzilla as an issue tracking tool for an organization that wants, due to their organizational structure and chain of command, to be able to say: "We want only the original Reporter to be able to VERIFY the bug he reported, since only he has the ultimate ability to check if the fix works for him". As of ver 2.14 (the one I am using), Bugzilla does not support anything like that; since the Assignee can always VERIFY the bug assigned to hime, without involving the admin or Reporter. This is not quite the matter of simply adding "Canverify" and "Canclose" groups that Philip Dalrymple's fix proposes, but related.

*** Bug 106884 has been marked as a duplicate of this bug. ***

*** Bug 28422 has been marked as a duplicate of this bug. ***

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

I think we might be heading more in direction of customised statuses (bug #101179), which should allow this and more.

Comment on attachment 13263 [details] [diff] [review] Patch to added mktar, and limit verify and close Templatization rewrite needed for the patch anyway. Is a separate fix still wanted? We've got bug 110947 bringing us better security system - and the custom statuses bug MattyT quoted before also matters - is this essentially automatically fixed by those? Also, I gather that we don't want a single new system group to avoid breaking stuff. So, essentially it means that this feature cannot be implemented with this kind of design.

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

*** Bug 319504 has been marked as a duplicate of this bug. ***

*** Bug 323712 has been marked as a duplicate of this bug. ***

Any movement on this enhancement? If I were savvy in Perl I'd offer to help.

*** Bug 327224 has been marked as a duplicate of this bug. ***

(In reply to comment #18) > Any movement on this enhancement? If I were savvy in Perl I'd offer to help. > No, no activity for almost four years now. The problem is more general, see bug 90619.

VERIFIED and CLOSED are no longer hardcoded bug statuses, and so we cannot enforce any rule about them. Future development will happen in bug 391059.