capabilities of forthcoming group changes

[Rob Browning]

Joel Peshkin <bugreport at peshkin.net> writes:

> I suspect that product "foo" is resticting ENTRY to some group of
> which your people are not a member. -

Ahh, I did have that set wrong.  Now the "incoming" group works as you
described (thanks), but unfortunately, people in client-a or client-b
can still remove the bug from their group when editing the bug and
thus make it visible to all members of product-foo.

Thinking a bit more about it, is there any setting like "mandatory if
member"?  i.e. the ability to say that for product foo, group client-a
is mandatory if the user is a member of client-a?

It seems like such a setting might solve the client-a/client-b
situation as long as a given user couldn't be associated with multiple
clients.  For example, for product foo you'd have:

  client-a: Mandatory-if-member
  client-b: Mandatory-if-member
  product-foo: ENTRY Mandatory/Mandatory CANEDIT

Then whenever a user submits a bug, it would automatically be assigned
both the product-foo group and the user's respective client group.
After that, people in client-* should only be able to see product-foo
bugs that were submitted by someone in their respective client group,
and they wouldn't be able to change the client-* group assignments.

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