rking inspector ...
User management may be a candidate for this kind
of treatment,
whereby a
user having responsibility for a sub-tree may put a user manager in
place for that subtree only. I beleive that xope does it this way too.
Exactly and I think the ACL security of Philippe is doing that as
well, at least this was one his of the initial requirements I
defined ...
Oh well, no, that's still not implemented yet ;). Yes it sounds
compelling a first but we really couldn't come up with good semantics.
Also there are no bit Pier installations deployed yet, so there's no
imminent need for that. But once it's needed it should not be too hard
to implement if you have come up with semantics first.
One of the things I learned is "do it the Pier way". That means
everything should be a structure, described by Magritte. Try to use
as much of the Pier/Magritte infrastructure as possible.
This has two advantages:
- You have to change less code to remain compatible with the latest
versions of Pier. Believe me, I've been doing this for over a year.
- You are more compatible with the rest of the Pier stuff out there.
Persistence, refactoring, ....
So by continuing this, users should be normal structures, editing a
user is just an edit command on a user, adding a user is just an add
command. See the following example:
http://spielverderber.seasidehosting.st/management/users
(password for the root user is 'chamdoow')
We had it otherwise before and it's really much better now. Less code,
easier to maintain, ... you name it.
Philippe