[Mapbender-dev] Discussion: Administration modules
Christoph Baudson
christoph.baudson at wheregroup.com
Wed May 28 04:46:46 EDT 2008
Len Kne schrieb:
> 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.
>
Thank you Len, I think being verbose is the right thing at the beginning
of a project like ours. We need to know a lot of things about your
background and your ideas. Please, continue to be verbose. We especially
need to be specific about the terminology, so that there are no
misunderstandings.
> 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)
>
Although I'm not maintaining a Mapbender installation I would assume
that only very few people actually get to see the admin screens. Even if
you have a 1000 users, I guess only a handful of them would be
administrators. Am I mistaken?
> 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.
>
We are not satisfied with mb_listGUIs either.
My approach would be similar to yours, but a default application, that
is always loaded. This could be what is depicted in your diagram
(diagrams are always helpful). This application could also contain a
module "user settings" (like "change personal settings" which is now
being displayed on top of mb_listGUIs). This application would also list
your other applications, like mb_listGUIs.
So how would this default application be determined? We could have
default groups, like "überadmin", "admin", "experienced", "novice",
"guest". These could be arranged hierachical, like "überadmin" is a
member of "admin", admin a member of "experienced" etc. These groups
solely serve the purpose of start-up profiles: If you start Mapbender,
it looks up your user in the user/group hierarchy and moves up until it
finds such a group/profile. Then it presents the default application
according to your profile. This would imply that such a default
application would belong to a group, not the user.
For a "novice" this could just be the application list (similar to
mb_listGUIs). A "guest" would see another application, also containing
that application list, but without the "change personal settings"
module. Another profile like "experienced" could have additional
administration functions, like you described above.
So what you called "single hierarchical admin module" would translate
into "default (optionally hierachical) admin application". Optionally
hierachical means that each different profile would have another
application which may not necessarily have to contain hierarchies. Some
could be dead simple.
We should keep things simple and not violate Mapbender's logic
(mb_listGUIs is a violation IMHO). If you think this idea is not
coherent, please alert me. It's always worth to think things over.
> 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.
>
Having a field "gui_type" would solve a similar purpose, yet I fear that
it is not enhancable: You can only store one value in a field, so what
if an application is of two types (read: has two tags)? You would have
to make up new kinds of entries, which would in the end lead to code
manipulation. In my opinion it is better to have a column for a
specified purpose. But if you have strong arguments, I can easily change
my mind.
Maybe isTemplate should be defined better. I have two scenarios in mind:
1) An application is a template like "gui", "gui1". This means it must
not be edited (even by an administrator), but it may be viewed. This can
be translated to "isReadOnly".
2) An application is a template like "admin1". It must not be altered,
and additionally, it must NOT be viewed (not even by an administrator).
This second property can be translated to "isAbstract", speaking in Java
terms. Or maybe "isContainer", as it could also be helpful for
classifying WMS container applications.
So a template can either be "isReadOnly" or both "isReadOnly" AND
"isAbstract".
Christoph
> 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
>>> _______________________________________
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mapbender_dev mailing list
> Mapbender_dev at lists.osgeo.org
> 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
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
_______________________________________
More information about the Mapbender_dev
mailing list