Closed
Bug 156691
Opened 22 years ago
Closed 22 years ago
Group behaviour allows user to edit other group's bug
Categories
(Bugzilla :: Creating/Changing Bugs, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 147275
People
(Reporter: steve.jones, Assigned: myk)
Details
Consider a software house with various departments who each have products. I want to set up Bugzilla so that anyone in the organisation can enter a bug against any product, but I want the bug reports to be editable only by members of the product's group. To do this, I have set usebuggroups=1 and usebuggroupentry=0, and set up some products/components, and some users, some in one group and some in the other. E.g. product1,component1,productGroup1, user1a,user1b product2,component2,productGroup2, user1a,user1b When user1a enters a bug against product1, a check box shows up at the end of the enter bug screen to allow user1 to decide whether to keep the bug visible only to productGroup1, or whether to allow anyone to see it. However, when user2a enters a bug against product1, no check box is visible. Looking in the mysql tables, it can be seen that, in the second case, the groupset for the bug is zero, meaning anyone can edit or see it. This seems like strange default behaviour. I can't see a way around this, so I have made the folloiwng 'fixes' to enter_bug.cgi and post_bug.cgi. # DENOVOMOD 10/07/02 SJ # I think there may be some bugs in the way groups are implemented. # The scenario I have in mind is that I set usebuggroups=1, and # usebuggroupentry=0, and then create products and users. This is # because I want allow anyone to enter bugs but only members of # the product's group to be able to see it and change it. # Without this change, if a user enters a bug against a product AND # is not a member of that product's group, no group permissions # check_boxes are displayed, and the bugs gets no groupset, and is thus # editable by anybody, which is not right for me. I want to allow # only people in the product's group to edit it. # To kludge this in, I have removed a check to make all the group # permission check_boxes show up. # # There is related "fix" in post_bug.cgi to handle the incoming # data from the user's browser. SendSQL("SELECT bit, name, description FROM groups " . # "WHERE bit & $::usergroupset != 0 " . # " AND isbuggroup != 0 AND isactive = 1 ORDER BY description"); "WHERE isbuggroup != 0 AND isactive = 1 ORDER BY description"); # ENDDENOVOMOD 10/07/02 SJ AND # DENOVOMOD 10/07/02 SJ # I think there may be some bugs in the way groups are implemented. # The scenario I have in mind is that I set usebuggroups=1, and # usebuggroupentry=0, and then create products and users. This is # because I want allow anyone to enter bugs but only members of # the product's group to be able to see it and change it. # Without this change, if a user enters a bug against a product AND # is not a member of that product's group, no group permissions # check_boxes are displayed, and the bugs gets no groupset, and is thus # editable by anybody, which is not right for me. I want to allow # only people in the product's group to edit it. # To kludge this in, I have put all the permissions in, whether or # not they correspond to the user's group set. # There is related fix in enter_bug.cgi #$query .= ") & $::usergroupset)\n"; $query .= ") )\n"; # ENDDENOVOMOD 10/07/02 SJ
Reporter | ||
Updated•22 years ago
|
Version: 2.14 → 2.14.2
Comment 1•22 years ago
|
||
Bbaetz, Joel: Take a look at this one. How does it relate to your scheming wrt the new group system?
Comment 2•22 years ago
|
||
This particular request will probably fall out of the product group stuff, which will make this all more generic and flexable.
Comment 3•22 years ago
|
||
Steve, This should be acheivable with the permissions model in bug 147275 by doing the following (and stretching the model under discussion a bit more) entry groupset for product1 restricts to a group containing all of the departments default groupset for product1 restricts to department1 required groupset for product1 does not restrict permitted groupset for product1 allows group restirctions to depeartment 1 canedit groupset for product1 depends... This hinges on a few key questions... 1) With this model, if a user outside of product 1 enters a bug against product 1, he will have no way to decide if it should be restricted to department 1, but a user in department 1 could subsequently drop the restricted-to-department-1 status. 2) The decision about the ability of the reporter to subsequently edit a bug in department 1's product (even though he can continue to see it) is something that would be decided at the granularity of the whole product. (unless we change reporter-can-always-see checkboxes to reporter-can-always-edit)
Reporter | ||
Comment 4•22 years ago
|
||
Bugzilla people, There has been quite a discussion about groups in Bugzilla. I have found a way to use Bugzilla 2.14.2 in unchanged form. For my application, it is OK to have an 'open' view/edit policy, because all the stakeholders are emailed anyway, and if something inappropriate happens, everybody would know and get the chance to sort it out between themselves. I have therefore set usebuggroups=1, and usebugsgroupsentry=0 and left the code unchanged. This gives the chance for 'maintainers' in the group to mark an incoming bug as private to the group, if they want to, but an outsider does not get this option on the enter bug screen. This is OK. The kludgey edit that I posted in the bug report was an attempt to mark the bug private to the maintenance group by default when entered by an outsider - the presence of the group check boxes on the screen was something I would actually have liked to surpress, but I couldn't find an easy way to do it. I heard about Bugzilla for the first time 2 weeks ago today, so I am obviously no expert. I am risking being told "fools rush in where angles fear to tread"! However, I had used a similar application in a code development situation, so I had some pre-conceived ideas about how they work. The application I am talking about (Proact WorkApp(http://www.proact.net/)) has some features similar to Bugzilla, although the system is more work flow oriented than Bugzilla, and the 'groups/users/bugs/products/states' functions were oriented towards making the work private, and a lot of effort had been put in to filtering the work to only the person assigned to the job, and masking it to 'inappropriate' persons. I sorry if this is a bit vague. Anyway, I have the table schema of Bugzilla in front of me now, and it is not clear to me whether Bugzilla groups are clusters of bugs, users or products or some combination. In any case, logic dictates that certain users and groups have certain rights to do certain things (create, edit or view) to bugs belonging to certain products. It is not easy to discern where the rights that can be granted to groups or users to do things reside in the DB model. I suspect that any fix must incorporate a table of access rights that only some users possess. These could include separate rights to view, enter or change the bugs-data belonging to certain products. Then a network of user-types could be set up. Groups would then be analogous to roles, e.g. users of productA, fixers of productA. Users of product A could enter and view it's bugs, but fixers could enter, view and 'progress' the bugs, for example. I don't know the proposed changes, but I can understand some of the tradeoffs. There would obviously be quite large administration and GUI changes if a sophisticated network of role/access control lists were implemented, and would that be right for Bugzilla anyway? I don't know. It's good for me like it is right now, but I can see situations where people might like to have "roles based" access rights.
Comment 5•22 years ago
|
||
Since this is not actionable and its underlying issue is being addressed under bug 147275, I duping it to that. *** This bug has been marked as a duplicate of 147275 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•