[Mapbender-dev] Discussion: Administration modules
Christoph Baudson
christoph.baudson at wheregroup.com
Thu May 29 04:29:08 EDT 2008
Hi Len,
Len Kne schrieb:
> See comments inline
>
> 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: Wednesday, May 28, 2008 3:47 AM
>> To: Mapbender Developer List
>> Subject: Re: [Mapbender-dev] Discussion: Administration modules
>>
>> 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
>> hierarchical, 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 hierarchical) admin
>> application". Optionally hierarchical 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.
>>
>
> Yes to the use of groups to determine which applications are shown to the
> user. I think this approach will follow Mapbender's logic by still
> controlling access by application. We can provide default groups as you
> described that may fit the needs of most installations, but the "überadmin"
> could also create custom groups to divide administration tasks.
>
> This does bring up another issue to consider. Can members of a parent group
> have access to its child groups (in terms of user management)? This is
> different than the current model. For example, on our installation of
> Mapbender, if I logon, I cannot administer users created by another person -
> only the owner, which is by default the creator of the user can administer
> them. This is a problem and must only get worse as the size of the
> installation gets larger. So while it would add some complexity to allow
> parent groups the ability to manage child group members, I think this would
> be a worthwhile addition. Kind of puts us back to looking at the tree
> design of groups/users. Actually, maybe it would not be a huge change -
> could the owner of the user by a group instead of another user?
>
To be honest with you, I'm not too familiar with the concept of users,
groups and owners (and the privilege inheritance) in Mapbender, as it
has been designed way back in the past before I joined the project. I
doubt that there is a foolproof concept behind it; at least it's not
well-defined and not at all documented; so it's hard to estimate the
effect of changes.
Maybe it's worth to take a closer look at the user/group model and try
to improve it. What I think would be interesting is to compare
Mapbender's user model to PostgreSQL's user model, see
http://www.postgresql.org/docs/8.3/interactive/user-manag.html
and following.
Just a short summary for those unfamiliar with that model: Their concept
is based on roles, which is more or less what I wanted to do with the
approach "there are no groups, just hierarchical organised users". In
Postgres, both users and groups are roles, but a user additionally has
the LOGIN privilege, which is quite elegant IMHO. Privileges like
CREATEDB could be translated to CREATEAPPLICATION.
What I like about Postgres is that it has all these well-defined
privileges and specific rules on how they are granted and inherited. I
would love to have an analyzation of this user model and would like to
know how (or more basically, if) it can be adapted to Mapbender. It's
quite similar, PostgreSQL grants access to databases and tables,
Mapbender grants access to applications and services.
Maybe we can shift the focus of your work to this segment, if you are
interested. A well-defined and well-documented user model would
definitely benefit the project a lot. Len, please let me know if you are
interested in doing this. If you are, you can start by comparing
Postgres user model to Mapbender's.
I would like to encourage other members of Mapbender to speak up and
share their experiences and ideas. I think it would be make Mapbender's
user model easy to understand if you could just say "it's like Postgres".
Christoph
>>> 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".
>>
>>
> Multiple fields is a better idea. I would suggest another field called
> "isWmsContainer" so that they can be hidden from users as well.
>
>
>> 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
>> _______________________________________
>>
>>
>> _______________________________________________
>> Mapbender_dev mailing list
>> Mapbender_dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>>
>>
>
> _______________________________________________
> 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