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: [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
