Group combinations

[Gervase Markham]

David Miller wrote:

> On 3/4/2004 8:58 AM +0000, Gervase Markham wrote:
>>Group inheritance? Maybe. But the problem then is that anyone in Group A
>>(including employees) files bugs in Group A mandatorily. If you
>>remember, we set this so Customer A people don't accidentally create
>>public bugs. That means that bugs employees file go into Group A, and
>>can never be seen by Customer B, even if that's who they are filing the
>>bug for. But this works the other way, too - the bugs go into Group B
>>also! The upshot is that bugs employees file can never be seen by any
>>customer! Oh dear.
> 
> It doesn't work this way.  The group restrictions on the bugs are set by
> product, not by who filed them.  The bugs would be restricted to the groups
> that were set on the product it was filed in, regardless of whether it was
> an employee that filed it or not.

I'm confused, then.

Is is true that, after filing, the groups on a bug never change except 
by explicit group-changing action from someone?

If so, why does it make sense that the groups for a bug are defined by 
the Product it's filed into? Surely it would be better to have (at least 
the option of having) them defined by the person who filed it?

Or, to put it another way: is it possible to achieve my scenario using 
the current groups system?

Gerv