Christoph Ideally WMS and WFS should be "ownable" by a group, for ease of management and for consistency throughout Mapbender. The changes needed to make this happen are more substantial then the user/group/application changes in the proposal.
Taking WMS for example, the field wms.wms_owner identifies the owner. That user has write access to the WMS and read access is controlled by access to an application - any user with access to an application with a WMS can read that WMS. One solution would be to separate WMS access from the application and control read/write access through a couple of tables (wms_mb_group & wms_mb_user) like what is done with an application. There are benefits to this approach (user level control to a WMS), but it separates service access from the application, does this violate the Mapbender design? Another option would be to put a WMS in a group whose members have management rights - this seems backwards and somewhat confusing to me. Any ideas from devs? Thanks Len > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Christoph Baudson > Sent: Monday, June 09, 2008 6:54 AM > To: Mapbender Developer List > Subject: Re: [Mapbender-dev] Motion to enhance the user/group model > > Hi Len > > before casting my vote I want to discuss one more thing. At > the moment, only users can own WMS and WFS. Is that some kind > of a problem? Do we want/need groups to own services? > > Beside this point I'm positive on your motion, as it only > adds functionality. If you don't need the enhanced group > model, you can stick with the old model. > > Thanks > > Christoph > > Len Kne schrieb: > > 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 > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Mapbender_dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/mapbender_dev > > > > > -- > _______________________________________ > > W h e r e G r o u p GmbH & Co. KG > > Siemensstraße 8 > 53121 Bonn > Germany > > Christoph Baudson > Anwendungsentwickler > > Fon: +49 (0)228 / 90 90 38 - 15 > Fax: +49 (0)228 / 90 90 38 - 11 > [EMAIL PROTECTED] > www.wheregroup.com > Amtsgericht Bonn, HRA 6788 > _______________________________________ > > Komplementärin: > WhereGroup Verwaltungs GmbH > vertreten durch: > Arnulf Christl, Olaf Knopp, Peter Stamm > _______________________________________ > > > _______________________________________________ > Mapbender_dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapbender_dev > _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
