Permissions GUI

Following up on my last post on this topic, the demo of the new permissions
system is now essentially complete (as per RFC30 and then some).
The code has been pushed to BK for your perusal. A new repository newperms
has been created, accessible as bk clone
[email protected]:/usr/local/repositories/newperms, viewable at
http://xaraya.com:15000/newperms.

 A running demo can be found at http://test.netspan.ch/xaraya (user: Admin,
pass: hello)

Hey, complete means "no showstoppers" (that I can see). This still needs a
bit more facelifting.

To recap here's what it lets you do:

1. You can define users and groups in a hierarchy with any number of levels.
Children can have multiple parents. Lower levels inherit properties of
higher levels. For the moment this is only true of permissions, but one can
imagine other properties it might be useful to inherit. This can lead to an
interesting discussion of dynamic data, and so on.

2. You can define permissions [objects] in a hierarchy with any number of
levels. Children can have multiple parents. Lower levels inherit the
permissions of higher levels..

3. You can assign permissions to users and groups. Because of inheritance a
single assignment can bestow compound permissions on a series of groups or
users.

4. As a module developer you can use the new API functions to create and
register [security] schemas at init time. Schemas are the hurdles which the
system will use to "challenge" your users at run time. When a challenge is
encountered in the code, the appropriate schema is compared with the user's
assigned permissions and those inherited from ancestor groups. This is
essentially an elaborate version of the current xarSecAuthAction function.

The demo system I've created is configured in 2 Xaraya modules: Participants
(for users and groups management) and Security (for permissions management).
The demo sets up a number of default groups, users and permissions. It also
creates some schemas for the Participants and Security modules themselves.
You can use these default schemas for the following:

5. You can test the permissions you set up against existing schemas. It
turns out this is a very useful feature. No more signing on as a user and
going through each module to test what you can and can't do. Instead, you
click on a user or group, choose a schema, and the system tells you whether
the user or group has the correct permissions for admission.

Here's what still needs to be done:

1. Haven't yet implemented functionality to selectively hide links to
modules. (nuncanada's request) I'm still mulling on how best to do this.

2. Instances need to be enhanced to include hierarchies. This could be done
for all sorts of instances (think download categories, or even files), but
at least needs to be done for groups themselves so that permissions can be
given to users to modify certain groups and their permissions (the example
of classrooms mentioned in the pub dev list some time ago).

3. Functionality to have a user only see his/her own data (suggestion by
Dracos).

4. Navigation needs a little work.

In addition, a bit more documentation is required to explain the details of
how inheritance of groups and permissions works. I've included a short
writeup on this in the next post and a txt file with the code.

Marc