[Mapbender-dev] Discussion: extending mb_group to contain other mb_groups as members

Tue May 27 08:18:37 EDT 2008

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
_______________________________________