Lukas Renggli wrote:
I thought that
structures already have their own environments. Are you
saying that a structure, having multiple documents, can have an
environment as one of those.
Yes, we would like to make the environment part of the page itself,
not only a reference to a different structure as it was before. Of
course you can still do that by embedding a different page.
Personally I find it a bit hard to understand ... ;-)
Anyway, it is (and also should) remain flexible enough so that people
can configure and setup their sites the way they like.
Thanks for this case study, it is helpful.
Personally, I am using a very different model:
(contents of the website)
system
(location of the management widgets)
components
(location of reusable components)
parts
(location of reusable layout parts)
designs
(location of full layout templates)
I use this model for my web-site, the Seaside web-site and a couple
of other Pier instances.
The difference between our approaches is that you have to manage the
permissions of each component individually. I found this quite difficult
to keep track of.
My approach gives permissions to each branch of the heirarchy, and so a
component inherits the permissions of the branch in which it is placed.
The advantage of this is visibility. I can know from the path of a
component what permissions it has.
I do not think
that the current permissions model is flexible
enough for
any but the simpleset use cases.
I assume that you are using the Unix Security framework? What you
have there is a (mostly) POSIX compliant security model.
I am successfully this model in quite complicated setup right now. I
am using it in an university course about software engineering:
admins (myself), assistants (myself and some other assistants), and
students. Furthermore, each student belongs to a group together with
one of the assistants. Permissions are set so that only assistants
can edit exercises. Each student can only edit his personal page and
the pages of his team. Each team has private pages (that only the
team can see) and public pages.
As always I have difficulty understanding these things and I have a
simple system very similar to yours...
Yours: admins, assistants, students and public.
Mine: superuser, admins, agents, and public (other).
So they are not so very different. However your admin level, can be
handled by granting superuser status, giving you only assistants and
students to manage permissions for. For any component you can grant two
different permissions, to the owner and group. If the students access is
specified by the group permissions then surely only one assistant can be
allowed to edit any one exercise, by granting that assistant ownership
privileges.
I have simply admins which can edit the site, and agents which can use
the site.
So if I assign a component as owned by user admin, and with use
privileges by the group 'agents' this works.
Ok, thats fine until I want to give more than one person admin rights
(without giving them super-user status), since the item can only be
owned by a single user rather than a group.
My solution to this is that I use pier-users as "roles" and have an
externally defined table of users which log in as a role. e.g. keith,
bob and eric once authenticated all log in as pier user "role-admin". So
a page owned by "role-admin" can be edited by keith, bob or eric. The
usage is defined by the group 'agents', and 'role-agent' is a member of
that group.
Lets say... I want to introduce a layer in between. Say an
agent-supervisors, who has slightly more privileges than an agent for
accessing the same component. Since the ownership can only be one user,
and that is "role-admin" and the group can only be one group which is
"role-agent" I am stuck I think.
Perhaps I was wrong perhaps what is needed is not for a group to contain
other groups, but for the owner to be a group rather than an individual.
If my owner could be a group, then... group "editors" could include
users "role-admin" and "role-agent-supervisors".
This would allow me to assign editing rights to 'editor' and using
rights to group 'agents'.
...
I think this boils down to the number of different uses for one
component. If the uses are "admin", "use" , "view" then in
some cases
this maps into owner, (user) group, other (public). Private regions of
a site would have to map "admin", "use" and "view" into just
owner and
group, since other is disallowed, and this is where I have got into trouble.
Still I am very glad to see pier moving forward,
Keith
Of course there is always a discussion between what is
the best
security model. There is also an ACL based security model available
in Pier. People have always been discussion what is a better
approach. Having tried both, I find the traditional POSIX permission
model easier to understand an manage, but that's certainly a personal
preference.
I think that if groups were to be able
to have groups as members that might help.
Such a model would not be more powerful than the existing one. If
that is requested, I guess, it could be easily feasible to implement
(probably by removing a simple check).
Lukas