[Mantisbt-dev] User groups patch.

[Nick T. <und...@us...>]

Hi All,

It seems my ISP is having fun with my email of late, I tried to send 
this message to the list last night and it doesn't apear to have arrived 
(along with a few other emails, one of which was to my work email 
address).  So if for some reason this is a duplicate please forgive me.

I first posted about this patch on the mantis developers forums a little 
while ago but it apears not very many people visit there so I decided to 
post here, most of the following is a repeat of that message with a 
little editing.

My company has recently, at my prompting, switched from an old bug 
tracking system written in-house to mantis. The only problem came moving 
all the users and projects over, the old system allowed you to create 
groups of users that then could be added to any numberof projects, the 
thought of having to create and keep track of all the permissions 
manually was somewhat daunting so in my own time I created a grouping 
system to make permissions some what simpler. I make this patch 
available so that people may use it in there own systems and point out 
anything I've missed and maybe eventually it will be accepted into the 
official source (so I wont have to patch it in every time I upgrade mantis).

The patch is available from:
    
    http://www.undergrid.org.uk/mantis/mantis_groups_cvs.tgz

and is current against CVS head at about 9pm GMT 11/07/04, unless 
someone has made huge changes recently it should patch on ok, you need 
to use the upgrade option in the admin directory to add the appropriate 
tables to your installation.

You'll find the main group management page in the manage page. Here you 
can define groups, assign users to groups and assign groups to projects 
with a given access level. The user edit page allows you to add and 
delete group assignments to users and the project edit page allows you 
to add and remove groups from projects, assuming you have the 
appropriate access level.

Some general info:

To add users to projects you currently need a global access level of 
$g_manage_group_threshold (default ADMINISTRATOR)

To add groups to projects requires a project level of 
$g_project_group_threshold (default MANAGER).

If a user has access to a project through one or more groups, or is 
assigned directly to a project that contains a group that he is a member 
of, the highest access level is used.

User to Group to Project access level will override global access level 
just as User to Project access level would.

No additional code is required in pages, the appropriate access_* 
functions have been modified to handle group permissions.

The "Edit Account" page now also lists groups that the user is assigned 
to. The "Inherited Projects" section lists projects that the user has 
access to via a group, the access level and which group gives this 
access. It is possible to have a project listed more than once if the 
user is a member more than one group that gives access.

The "Manage Accounts" section of the "Edit Project" page now lists users 
with access via a group as well as directly or via global access level 
(as it did previously), only users that are directly assigned to a 
project will have a remove link, users accessing the project via a group 
will have to be removed from the group in either the group edit page or 
the user edit page.

There is also an "Access Summary" option in the main manage menu, this 
shows all users and the groups and projects they are associated with 
along with the access levels each relationship has.  A warning though, 
if you have a lot of users this can be a very long and very database 
intensive page.

A final note, in theory you can add this patch to a current system and 
remove it again without any problems, it adds three tables and does not 
modify any existing ones,  however as always take backups first!

If anyone has any comments, questions or suggestions, please feel free 
to contact me.

Nick.