capabilities of forthcoming group changes

[Rob Browning]

Joel Peshkin <bugreport at peshkin.net> writes:

> The only way to do this today is to use one product per client.  The
> options are explained in the editproducts page for editing group
> controls.

Right, I'd thought of that.  I just didn't know if anyone had a more
clever solution.

> Forcing restrictions based on the membership of the submitter saying
> that Group A must restrict to Group A but they don't have to if they
> are members of both Group A and Group B would be an interesting
> trick. After all, your own staff will need to be members of all of
> these groups and their membership should not require them to restrict
> bugs to be visible by only other people who are members of all of the
> groups.

Right.  There also might be a case where a user should be allowed to
submit bugs for more than one client (i.e. they work for two clients).

> If anyone has an idea of a consistent way to express this, jump in
> anytime.

If there were a way to list groups for a product that were "mandatory
on entry if the submitter is a member", that might help.  For example,
for product-foo you could list all the client groups that are allowed
to submit bugs for product-foo (say client-a, client-b, client-c, for
example).  Then when a user enters a bug, if they're in the client-a
group, that group will be automatically assigned to the bug without
presenting a checkbox.  Of course you'd still have an editing problem.
i.e. even if the client-a user is allowed to edit bugs, they shouldn't
be allowed to change the client-a group assigned to the bug.

I guess you might be able to fix that if you were willing to make
editing a bug's group a separate privilege from other editing
(editbuggroups?).  In that case, staff would be allowed the
editbuggroups privilege (in case a bug needs re-filing), but clients
wouldn't.  Also, this would have the side effect that any user in more
than one client group would create bugs that were visible to all the
client groups they belong to.

In any case, I have this feeling there's a much better way to handle
that, but the above is the simplest thing I've thought of so far...

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4