I have multiple products:
Product A
Product B
I have multiple groups:
Group DevA
Group UsersA
Group DevB
Group UsersB
I have multiple users:
W (Developer)
X (User)
Y (Developer)
Z (User)
The products all need to be accessible seperately. That is, no one can
see Product A unless they belong to a group that has access to it. The
products are NOT open to the public. That being said, I would like to
set up my groups and users as follows:
Product A:
Group DevA with read access and edit all bugs in this product only (can
write but not necessary; I'd prefer that no bugs are associated with
this group.)
Group UsersA with read and bug entry but NO bug edit
W, I assume, would be assinged to both DevA and UsersA
X, I assume, would be assinged to just UsersA
What, then, is the setup for the groups permissions?
Product B:
Exactly the same. But, developers and users of B don't have
permissions to Product A unless assinged in Product A groups.
Is this possible and if so, how?
Any help is greatly appreciated,
Jeremy
Using 2.20
I've found a work-around but it's not ultimately what I need:
If I give the members of Group DevA the editbugs permission
individually, they can edit bugs just fine. While belonging to only
the UsersA group, the can only see Product A and can edit all bugs
associated with UsersA.
That's all fine and good but that negates the need for the DevA group
all together. Since I can't apply the editbugs permission to a whole
group, it requires me to assign that permission to all individuals whom
need it and would normally be assinged to a Dev group.
Is there a combination of group permissions that enables this scenario
without having to give permissions individually to each user who needs
it? It would be much more efficient to just assign users to groups who
have the appropriate permissions already in place.
Again, Thanks.
Jeremy
13 Dec 2005 08:49:22 -0800, jlsl...@gmail.com <jlsl...@gmail.com>:
> I have multiple products:
> Product A
> Product B
>
> I have multiple groups:
> Group DevA
> Group UsersA
> Group DevB
> Group UsersB
It's easier if you set up (and thus, name) your groups from a product
view rather than from a user view. It seems to me you'll get close to
what you want if you have the groups ReadCreateA, EditA, ReadCreateB,
EditB.
Have DevA people be a member of ReadCreateA and EditA, and have UsersA
people be a member of ReadCreateA. Similar for the B product.
> The products all need to be accessible seperately. That is, no one can
> see Product A unless they belong to a group that has access to it. The
Take care not to fall into the trap of thinking "*a* group that...".
In most cases, you need to say "...unless they belong to all groups
the product is restricted to".
> Product A:
ReadCreateA: Entry/Mandatory/Mandatory/--
EditA: --/NA/NA/Canedit
Similar for Product B.
> Group DevA with read access and edit all bugs in this product only (can
> write but not necessary;
For this, you need to give editbugs privileges to developers. If you
want to restrict editbugs privileges in other products, you need to
set up a group they are *not* a member of as xx/xx/xx/Canedit for the
other products. In your particular setup, this is already covered by
the EditA and EditB groups.
> I'd prefer that no bugs are associated with
> this group.)
This is not possible as visibility restrictions are determined
per-bug. You can see a given bug if you are member of all groups it
belongs to.
Kind regards
Marc
--
http://wurblzap.net/
Bugzilla hosting and professional support
Your reply is greatly appreciated. The concept of "unless they belong
to all groups" has helped me figured it out a little better. I
initially tried the following setup:
ReadCreateA: Entry/Mandatory/Mandatory/--
EditA: --/NA/NA/Canedit
With a regular user belonging to ReadCreateA only. This works
perfectly.
Then I added a developer to ReadCreateA and EditA with no other
permissions (i.e. editbugs). The developer could NOT edit the bugs
created by the regular user. If I understand correctly, the developer
by belonging to the canedit (EditA) group should be able to edit all
bugs in the Product.
Is this correct or does the developer still need the "editbugs"
permission assigned to them as well as belonging to the ReadCreateA and
EditA groups?
I think the later may be the answer because if a developer is given
editbugs but still not assinged to the EditA group, they won't be able
to edit the bugs. So, the developer would need to be assigned to
ReadCreateA, EditA, and have editbugs permission to edit the bugs in
the Product.
For my purposes, however, this adds one more layer of complexity. I
have given all users that belong to ReadCreateA the ability to edit the
"priority" field by editing the process_bug.cgi as follows:
if (($field eq "priority") {
if (Bugzilla->user->groups("ReadCreateA"))
{
return 1;
}
else {
$PrivilegesRequired = 2;
return 0;
}
}
That worked flawlessly with my previous setup of having no EditA group.
Users of ReadCreateA could edit the priority field and only users with
the editbugs permission could edit the other fields (with exception of
the reporter, assignee, etc.). Now with the current setup of:
ReadCreateA: Entry/Mandatory/Mandatory/--
EditA: --/NA/NA/Canedit
Users belonging to group ReadCreateA can no longer edit the priority
field and process_bug.cgi kicks the "You are not permitted to enter
bugs in Product ..." error.
I checked the process_bug.cgi for any instance of the "canedit"
permissions and for anything that may be returning 0 on not belonging
to the "canedit" group but found nothing. My custom priority entry in
the process_bug.cgi is right before the "At this point, the user is
either the reporter or an unprivileged user" entry.
So, the question is: Is it even possible for me to allow users that
only belong to the ReadCreateA group to edit only the priority field
with an EditA (canedit) group present?
Does the developer still need the "editbugs" permission assigned to
them as well as belonging to the ReadCreateA and EditA groups?
I hope my post has been comprehensible.
19 Dec 2005 13:25:46 -0800, jlsl...@gmail.com <jlsl...@gmail.com>:
> Is this correct or does the developer still need the "editbugs"
> permission assigned to them as well as belonging to the ReadCreateA and
> EditA groups?
yes, they'll need editbugs permissions. See my previous mail.
> For my purposes, however, this adds one more layer of complexity. I
> have given all users that belong to ReadCreateA the ability to edit the
> "priority" field by editing the process_bug.cgi as follows:
[...]
> Users belonging to group ReadCreateA can no longer edit the priority
> field and process_bug.cgi kicks the "You are not permitted to enter
> bugs in Product ..." error.
>
> I checked the process_bug.cgi for any instance of the "canedit"
> permissions and for anything that may be returning 0 on not belonging
> to the "canedit" group but found nothing. My custom priority entry in
> the process_bug.cgi is right before the "At this point, the user is
> either the reporter or an unprivileged user" entry.
Yes, this check happens in another place. Look for the string
product_edit_denied in process_bug.cgi. I'm afraid it'll be
non-trivial to implement what you want :(
Thanks so much for your assistance. Hopefully this post will help many
others out there with a similar situation.
Respectfully,
Jeremy