<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16640" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2>Greetings</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>After discussion at
the last several IRC meetings, I motion to:</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>1. Add a table
mb_group_mb_group</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>2. Allow groups to
own applications/guis</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>3. Allow an owner of
a group to administer members of that group</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2>Background</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>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. </FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2>Link to previous
discussion</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial size=2><A
href="http://lists.osgeo.org/pipermail/mapbender_dev/2008-June/001216.html">http://lists.osgeo.org/pipermail/mapbender_dev/2008-June/001216.html</A></FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=995422419-03062008><FONT face=Arial
size=2>Len</FONT></SPAN></DIV></BODY></HTML>