[Mapbender-dev] Discussion: Administration modules

Tue May 27 17:28:43 EDT 2008

Greetings

Sorry upfront for the long, but hopefully not rambling email.  Christoph's
comments, along with the last couple IRC meetings and possible (pending)
changes to elements/gui_elements have clarified my thinking.

First, some background on my perspective of Mapbender.  I've been a
Mapbender users since March 2007 while working on a project that is bring
mapping and GIS to K-16 education (maps.umn.edu).  I work with Eco
Education, a non-profit group which helps students explore their local
environment.  Eco Ed provides the curriculum, I provide the mapping tools
(Mapbender/MapServer/Postgres/PostGIS).  We also have three freshman level
classes at the University using Mapbender to varying degrees.  All told, we
have about 10 Mapbender applications currently being used.  I am the "über"
admin, but there is a person at Eco Education who does a fair amount of
administration as well.

One of the ideas for the administration modules I have been suggesting is a
single hierarchical admin module.  Focusing on the hierarchical aspect
first, I offer this example.  In my implementation of Mapbender, we have
many teachers who would like to do some of their own customization of the
application we give them.  For example, they may want to change the body or
imprint colors, turn specific modules on/off, or change some of the WMS
parameters for their application.  Of course the teachers are not using this
terminology, they are thinking colors, tools, and maps.

So by hierarchical, there would be a simple admin module (this would be a
new module) that could handle some of the simple tasks.  From this simple
admin module, there would be access to more in-depth admin functions.  Back
to the teacher example, most teachers would not go past this initial admin
screen, but some would go deeper and get into the guts of Mapbender.  Using
a tree structure to allow people to easily get into admin modules and give
the impression of a single admin module, while using all of the core admin
modules currently developed (with improvements on validation, CSS, and uses
of classes).

One question I will throw out is who is the audience of the admin modules?
Is it someone with web mapping skills, a programmer or a novice user?  Does
the administrator manage many applications or just a couple?  How many users
and groups?  (During the IRC, SEVEN mentioned that there are Mapbender
installations with over a 1000 users, wow)  

Currently mb_listGUIs is the starting point which lists all of the
applications.  One idea would be instead of listing the applications,
present a tree with different admin functions, as well as the available
applications (see the attached conceptual diagram).  As an admin moves
through the tree, they will get to the appropriate set of admin modules.
The current model of assigning user rights by application would still be
followed.  

I like Christoph's idea of adding the field isTemplate to GUI, this would be
helpful.  Another thought would be a field gui_type which would specify if
it was an application, admin module, template, or WMS container.  This would
give options for hiding non-mapping applications from the average user.

Thanks for your feedback

Len

-----Original Message-----
From: mapbender_dev-bounces at lists.osgeo.org
[mailto:mapbender_dev-bounces at lists.osgeo.org] On Behalf Of Christoph
Baudson
Sent: Tuesday, May 27, 2008 7:19 AM
To: Mapbender Developer List
Subject: Re: [Mapbender-dev] Discussion: extending mb_group to contain
othermb_groups as members

At yesterday's IRC meeting we agreed upon adding a new table
"mb_group_mb_group" to model the new relation of groups containing other
groups. We think this is the easiest way which will guarantee fast results.
Another side effect is that we only add a table and not change existing
tables.

BTW, Len, please use the following JS tool to visualize the user/group
relations:

http://blog.thejit.org/wp-content/jit-1.0a/examples/rgraph.html

Just kidding :-) But it looks pretty cool and I wanted to share it.

Christoph

Christoph Baudson schrieb:
> Hi Len,
>
> I'm sending this to the developer list directly, as a lot of people 
> might be interested in joining the discussion.
>
> Please find my comments inline.
>
> Len Kne schrieb:
>> Christoph, Lars
>>
>> I've been spending some time looking at the Mapbender developer 
>> pages, getting familiar with the jQuery library, and playing with 
>> Eclipse.  And thinking about the administration modules from 50,000 
>> feet.  I do have some questions on the process of getting this large 
>> task completed this summer.
>>
>> First, a more specific question.  At the Monday IRC meeting Christoph 
>> had mentioned that we should make a motion to allow groups to be 
>> members of groups.  Is this something I can submit to the developer 
>> list?  If so, I would propose adding a new table to the DB called 
>> mb_group_mb_group with two fields similar to the existing 
>> mb_user_mb_group table.  Minor additions to mb_getGUIs.php would be 
>> needed to query this new table and a script similar to 
>> mod_group_user.php to allow users to make groups members of groups.  
>> If this seems like a good approach, I can write it up more 
>> completely.
>>   
>
> We can discuss this at the IRC meeting today.
>
> I'm not sure. The easiest would be adding a mb_group_mb_group table. 
> But maybe we should consider this idea: Imagine there are no users, 
> there are only groups. These groups can be arranged hierarchical like 
> a tree. The leaves of that tree are called users, the inner nodes are 
> called groups. The "is child" relation would then translate to 
> "user/group is contained in this group". By this way we could simplify 
> the data model (having both mb_user_mb_group and mb_group_mb_group 
> would be redundant in a way).
>
> I think both solutions have their pro's and con's, and maybe someone 
> even has a third approach.
>
>> Back to the big picture of the administration modules.  As I 
>> mentioned in my proposal I'd like to see a single administration 
>> module using tabs to provide hierarchical access to the functions.  
>> Commonly used functions (user management, WMS, etc.) would be right 
>> up front with some drilling down to get to more advanced functions 
>> (GUI elements, WFS customization, etc.).  So take admin_de_services, 
>> admin1, and admin2_de and combine them into one interface.  I'd build 
>> off the design (look and use of AJAX) of the new module used to edit 
>> WFS.  Going even further, using "Internationalization", multiple 
>> languages could be supported within a single admin module.
>>   
>
> Just to clarify: what do you mean by "a single administration module"? 
> Do you mean just the usage of tabs to wrap existing modules (as it's 
> done in the map applications), or really a new module?
>
> (BTW, do you really want tabs, or wouldn't it be better to have some 
> kind of a tree? Basically it's just the same, but it has arbitrary 
> depth. I guess the tree used for WMS in the map applications could be 
> adjusted  - but I'm not sure if you are interested in doing this 
> adjustment).
>
> With the design, we need Lars' help. I guess he has some more 
> interesting ideas about HTML validity and elegant CSS usage. Maybe 
> Lars can sum up his ideas in a few sentences.
>
> The internationalization approach is very sensible IMHO, I can help 
> with that.
>
>> Combining the admin functions into one module could cause an issue 
>> with giving rights to users to do certain administrative tasks.  
>> Currently, access can be controlled to the administrative GUI's, thus 
>> restricting what users can do.  If all of the functionality was in 
>> one module (like
>> admin1
>> currently has), some users may be able to get into too much of the 
>> administration.  I could see handling this issue with groups by 
>> restricting certain tabs or functions within the new administration 
>> module to specific group membership.
>>   
>
> First of all, each single module has to check the permissions of the 
> current user. So if a user tries to access a module and has no valid 
> permission, the module will not be accessible. And beware: The 
> application "admin1" is supposed to be a container only! It should 
> only be used as a template for creating your own administration 
> interfaces (but I guess we have not made this clear enough in 
> Mapbender - maybe we should add a column "isTemplate" to the table 
> gui? We could avoid displaying these template applications then).
>
> So your approach is an "intelligent" tab structure which detects the 
> module permissions and only displays the valid entries? I'm not sure 
> about this, as this sounds like a contradiction to the current 
> Mapbender approach, which is "grant permissions to modules by granting 
> permission to applications containg these modules".
>
> What I'm trying to say is this: If you grant a user access to this 
> "über" admin application (which contains all modules, like admin1), 
> this user also has permission to ALL modules (as there is no 
> mb_user_element table). Would it make sense to have a mb_user_element 
> table? I guess not really, as this would create quite an 
> administration overhead. But if you have another idea, I'm glad to 
> discuss it.
>
> I think it's important to discuss these issues intensely up front, so 
> there are no misunderstandings. We should not hurry with design. I 
> guess once we have figured out what we want, coding can be done really 
> fast.
>
>> My thought is to write-up these ideas in a more coherent text and 
>> send it to both the users and developers list for comment.  What is 
>> the norm for Mapbender development?  When starting to code, I was 
>> planning on starting with users and groups as they probably will not 
>> be greatly affected by the proposed changes to "elements".
>>   
>
> Yes, this may be a good place to start. Let's discuss this idea first 
> and later this week we send a motion to the dev list. After this, we 
> can start coding.
>
>> I guess that's enough for now.  I'm going to try start getting to 
>> work earlier (although not on Thursday this week) so there will be 
>> more chance of catching people on IRC (Minneapolis is UTC-6).
>>   
>
> If you feel the need for discussion, we can make an additional 
> appointment at a more appropriate time. I would be happy to join IRC 
> later from home, I could be available sometime between 1300 and 1500 
> Minneapolis time, just let me know up front and we can meet and discuss.
>
>> Thanks
>>
>> Len
>>
>> -----Original Message-----
>> From: Christoph Baudson [mailto:christoph.baudson at wheregroup.com] 
>> Sent: Wednesday, May 21, 2008 6:31 AM
>> To: Len Kne
>> Cc: Lars Beck (WhereGroup)
>> Subject: GSoC Mapbender
>>
>> Hi Len,
>>
>> as you will be working on the administration modules, you will also 
>> have to
>> consider layout and styles.
>>
>> I'm cc'ing this mail to Lars, who is your co-mentor; he can help you 
>> with
>> CSS and generally creating a visual concept.
>>
>> Thanks
>>
>> Christoph
>>
>> -- 
>> _______________________________________
>>
>> 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
>> christoph.baudson at wheregroup.com
>> www.wheregroup.com
>> Amtsgericht Bonn, HRA 6788
>> _______________________________________
>>
>> Komplementärin:
>> WhereGroup Verwaltungs GmbH
>> vertreten durch:
>> Arnulf Christl, Olaf Knopp, Peter Stamm
>> _______________________________________
>>  
>>
>>
>>   
>
>

-- 
_______________________________________

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
christoph.baudson at wheregroup.com
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________

Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________

_______________________________________________
Mapbender_dev mailing list
Mapbender_dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: admin.pdf
Type: application/pdf
Size: 15411 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20080527/68ac146b/admin-0001.pdf