[Mapbender-dev] Discussion: Administration modules
Len Kne
knex0001 at umn.edu
Fri May 30 15:34:53 EDT 2008
Greetings
Per the ongoing discussion on administration modules, I have looked at how
users, groups, and access to applications are currently managed and present
some alternative models. The attached document presents three conceptual
scenarios:
1. Current Mapbender User/Group Model - This is my understanding of how it
works now. This information is based on pages on the wiki (below) and my
own experience.
http://www.mapbender.org/User
http://www.mapbender.org/UserAndInterface
http://www.mapbender.org/Benutzerverwaltung
http://www.mapbender.org/Benutzer_anlegen_und_editieren
http://www.mapbender.org/Root
2. Mapbender User/Group/Group Model - This version takes into account the
newly agreed idea of allowing groups to be members of groups.
3. Alternative Mapbender Role Model - This is a model based on how Postgres
handles DB administration. It proposes a significant change to how
Mapbender currently manages user access to applications.
I have not moved past conceptual models to how models 2 or 3 would be
implemented. 2 should be fairly straight forward and does not have to affect
any current installations (backwards compatible). 3 would certainly be some
work and a migration process would be needed for current installations.
An important question for discussion is are any of these changes necessary
or important to the development of Mapbender? Do Mapbender users want them?
For me, model 2 would fit most needs of the current installation of
Mapbender I operate, but features of 3 would be helpful. How about other
Mapbender installations?
Thanks
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: Thursday, May 29, 2008 3:29 AM
> To: Mapbender Developer List
> Subject: Re: [Mapbender-dev] Discussion: Administration modules
>
> 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
> _______________________________________
>
>
> _______________________________________________
> 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: Mapbender_User_Model.pdf
Type: application/pdf
Size: 71266 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20080530/7f847c03/Mapbender_User_Model-0001.pdf
More information about the Mapbender_dev
mailing list