156691 - Group behaviour allows user to edit other group's bug

Status: RESOLVED DUPLICATE of bug 147275

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Steve H Jones]

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

Comment 1

[Jouni Heikniemi]

Bbaetz, Joel: Take a look at this one. How does it relate to your scheming wrt
the new group system?

Comment 2

[Bradley Baetz (:bbaetz)]

This particular request will probably fall out of the product group stuff, which
will make this all more generic and flexable.

Comment 3

[Joel Peshkin]

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)

Comment 4

[Steve H Jones]

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

[Joel Peshkin]

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 ***