it would be desireable to be able to assign certain
permissions to users.
A user of the issue tracker doesn't necessarily have
write access to the code, nor should he.
Following the relational model, if all issues have a
'group id' (which could coincide with some other
attribute of the issue (*), a table could be created
mapping users to permissions w.r.t. these groups.

This mechanism could be used by roundup to determine
whether to
provide r/w access to certain kinds of data.

Issues could only be assigned to 'developers', not all
'users'.
Bugs can only be closed by 'developers', milestones
could only
be modified by 'release managers', etc.

* this may indicate that a new type could represent
this concept, or
something similar to 'setkey()', so a specific
attribute becomes the
group id, which then is the choice of the DB designer...
On the other hand, if permissions should be associated
with individual
attributes ('only release managers can set a
targetmilestone attribute') things become quite a bit
more complex...

Logged In: YES 
user_id=6405

Done.  
 
The "group" concept you discuss is fairly application-specific and 
belongs in specific code in the instance. An extra property on issues, 
an auditor and a custom CGI interface could handle the job.