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
