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

[Christoph Baudson]

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
_______________________________________