[Mapbender-dev] Motion to enhance the user/group model

[Len Kne]

Greetings
 
After discussion at the last several IRC meetings, I motion to:
 
1. Add a table mb_group_mb_group
 
2. Allow groups to own applications/guis
 
3. Allow an owner of a group to administer members of that group
 
Background
 
The overall goal of this motion is to simplify the administration of users,
groups, and applications.  Allowing groups to be members of groups may
reduce the number of groups needed in a Mapbender installation.  Allowing a
group to "own" an application and owners of a group to edit members will
help Mapbender installations with multiple administrators.  Some more
details for the three parts.
 
1. Adding the table mb_group_mb_group will allow groups to be members of
other groups.  This will simplify "read" access to applications by allowing
a hierarchical structure of groups.  The table will consist of two columns,
fkey_mb_group_id and fkey_mb_parent_group_id.  Minor changes will be needed
in class_user to query the new table and determine user application
permissions.  This change does not remove or change any current
functionality of the user/group model.
 
2. Most of the pieces needed for groups to own applications are already in
place, they just need to be enabled.  Currently gui_mb_group.mb_group_type
is unused, but could perform the same function as gui_mb_user.mb_user_type.
The function getOwnerByGui in class_administration already queries to
gui_mb_group.mb_group_type to assign application ownership, but most modules
are currently not using this class.  As part of the administration module
work this summer, I propose to change the modules to use this administration
class.  The only step left for groups to own applications is to create a
simple module for people to add the owner attribute to the table (similar to
mod_gui_owner).  This change does not remove or change any current
functionality of the user/group model.
 
2a. Optionally, it may make sense to combine the functionality of 1 and 2
together.  Currently class_user creates an array with what applications a
user has "read" access to and class_administration creates an array of
owners with "write" access.  Combining these into one function would produce
an array with user access level to an application (by including owner, they
have write access).  This could allow for other levels of access ton an
application in the future.
 
3. Currently users can only be edited by a single owner.  This makes it hard
for Mapbender installations with multiple administrators to manage users -
for example an administrator may not be able to manage a user that is using
an application they manage because the user was created by another admin.
This change will create a class that will allow an owner of a group to fully
manage members (users and other groups) of the group, including editing,
creating, and deleting.  This way administrative functions could be
distributed.  No new tables or fields (with the exception of the new table
in 1) are needed for this motion.  
 
3a. This motion could have security implications for current Mapbender
installations depending on how groups are setup.  It is therefore
recommended that a new variable be added to Mapbender.conf to allow
administrators to enable/disable this functionality.
 
Link to previous discussion
http://lists.osgeo.org/pipermail/mapbender_dev/2008-June/001216.html
 
Thanks
 
Len
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20080604/cb8f0211/attachment.html