The client prototypes as of 020531 included basic controls for specifying who had permission to read from and write to each object. This is a simplification of the CORK permissions mechanism in that the "write" permission includes:
- Permission to make any change the object
- Permission to change the permissions of the object. Doing this also makes the user who changed permissions the new "owner" of the object.
- Permission to delete the object. There is currently no way in the UI to actually delete objects from the database -- all you can do is detach them from the hierarchy.
This simplification reduces UI complexity, but causes problems in a number of cases, e.g.:
- If I want to create an open, swiki-like site within a site that I own, I must give write permission on the swiki directory to everything that I want to have the ability to contribute. Implications of this include:
- Any user can (inadvertantly or otherwise) change the permissions on the directory, effectively locking others (including myself) out.
- Any user can delete the directory. In practice this is forbidden by the UI, since actually removing the swiki directory would require a change to the swiki's parent directory, which I presumably haven't left open.
- There is no way to give away an object without the active involvement of the recipient. In practice this is primarily just useful for administrative tasks, and could therefore be handled by a special admin command.
Possible solutions to this include:
- Modify permission change logic so that changing permissions does not change the owner. This would at least prevent the original owner from being locked out, but would completely eliminate the ability to give objects away. Care would have to be taken to disable options that would lock the user who was changing permissions out of the object (preventing them from recovering from a mistake).
- Add a "Permission to change permissions" panel to the current permissions UI, allowing the owner(s) to explicitly determine who can modify the permissions. This adds UI complexity, but is more flexible and may actually add some additional clarity to UI.
Long-term, this issue suggests that we may want to introduce a notion of destructive vs. non-destructive Change objects in CORK, to better support "append-only" permissions in a generic way.
|