Hi Len,
thanks for your detailled analysis and the diagram. This makes things a
lot clearer.
I guess we have to check if all necessary privileges can be modeled with
the current data model. If not, we might have to consider adopting model
three. We should only move on to model three if it had significant,
immediate advantages. If I was to re-implement Mapbender I would
definitely use this model, and not the application-based privilege
granting model.
Regarding model two, we should define the rules of privilege
inheritance. The most relevant change would be that groups could be
owners as well. Now, groups can neither be owners of users nor of
applications. We should discuss this at today's IRC meeting.
Christoph
Len Kne schrieb:
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
---------------------------------------------------------------------
-
--
_______________________________________________
Mapbender_dev mailing list
[email protected]
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
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
_______________________________________________
Mapbender_dev mailing list
[email protected]
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
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
------------------------------------------------------------------------
_______________________________________________
Mapbender_dev mailing list
[email protected]
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
[EMAIL PROTECTED]
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________
Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Arnulf Christl, Olaf Knopp, Peter Stamm
_______________________________________
_______________________________________________
Mapbender_dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/mapbender_dev
