#134: Reader and Editor roles
It is too difficult to share a private or restricted document with another person or group. By introducing Reader and Editor roles, the Sharing tab can be used to let any given user or group the right to read or edit any object.
- Proposed by
- Martin Aspeli
- Seconded by
- Alexander Limi
- Proposal type
- Architecture
- Assigned to release
- State
- completed
Motivation
User A creates a Page. The workflow is such that this page is private to him (this is the case with How-tos in the PloneHelpCenter for example). Whilst working on it, he wants to let User B review his changes, whilst User C should be allowed to edit the page as well.
The obvious place to do this would be the 'Sharing' tab. However, a regular user can assign only the 'Owner' role to another user, which obviously gives that user full read/write permissions.
Proposal
- Add two new roles: Reader and Editor
- Reader has the View, Access content information and List folder contents permissions enabled at the portal root level
- Editor has these permissions, as well as Modify portal content
These roles will be acquired in the existing and custom workflows.
- Devise a way to allow any Owner to assign Reader and Editor local roles from the Sharing tab.
- Ensure the 'Sharing' tab is enabled for the standard content items by default, not just on folders.
Implementation
Adding the new roles and permissions should be trivial. The existing workflows may be updated to include them, but having them acquire permissions from the portal root is probably sufficient. Custom workflows can obviously redefined them as needed, but well-behaved content should not use anything outside the CMF core permissions for viewing and editing content.
The trickier part is to allow the user to assign the Reader and Editor local roles to other users. There are two main routes to achive this:
- Make sure all members also have Reader and Editor roles, which should let them delegate those roles to other members
- Fake the roles on the 'Sharing' tab (or even provide some custom UI for these "special" roles) and assign the roles in unprotected code that does the appropriate checks itself.
We may want to provide some means for a site-administrator to turn this behaviour off, or only allow certain roles to delegate. The second option could involve a method protected by a 'Delegate responsibility' permission or similar, that defaults to being on for all members, protecting the method that managed the adding and removing of the delegated permissions.
Risks
- Existing workflows may need updating to work with the new roles. This would happen if they relied on non-standard permissios for viewing or editing content. Note that in general, doing so is discouraged.
- The generic UI for role assignment on the 'Sharing' tab may be unsuitable for the more specific tasks of 'let this user see my content' or 'let this user edit my content'.
- Plone should still work with these roles removed: Some sites may remove them.
doing this in production