Feature Proposal: Implement "additive" Topic level ACLs
Currently Topic level ACLs completely override web level ACLs. For ex,
- ALLOWWEBVIEW = JoeUser
- ALLOWTOPICVIEW = FredUser
results in JoeUser being unable to view the topic. This has been a fundamental design of Foswiki ACLs since the beginning.
The TWiki project has seen the need and implemented Additive ACLs, where a Topic ACL can be specified to "add to" the Web level settings. This has benefits where a site needs to relax ACLs on individual topics, but don't want to be forced into editing all topics whenever Web level ACLs are changed.
Description and Documentation
The TWiki implementation is described as:
You may want to allow or deny access to a topic in addition to the ALLOWEB* or DENYWEB* specifies. In that case having + as the first non-space character of ALLOWTOPIC* or DENYTOPIC* has that effect.
For example, the following setting allows view by MarketingExecGroup in addition to the people ALLOWWEBVIEW allows.
Set ALLOWTOPICVIEW = + Main.MarketingExecGroup
We have a couple of implementation choices:
- Add it to the
Foswiki::Access::TopicACLAccess as a default feature.
- Create a new alternative
It appears to be a very straight forward implementation in TopicACLAccess - if the ALLOWTOPIC setting begins with a +, prepend the corresponding ALLOWWEB setting.
- This is purely additive
- Applies to the entire setting. It is not per user.
- eg. you cannot do JoeUser +FredUser -BadUser
As this feature does seem to have some reasonable usefulness, and appears relatively simple. I think incorporating it into the current ACL implementation would be preferable to creating a new implementation.
We could also make it configurable.
- ALLOWWEBCHANGE = WebMaintenanceGroup
- ALLOWTOPICCHANGE = + JoeUser
Anyone in the WebMaintenanceGroup can edit the topic, as can JoeUser.
No impact to existing topics / installations.
-- Contributors: GeorgeClark
- 06 Feb 2017
I'm not 100% sure that this is the right solution. What my user could use is a per web AdminGroup
, where certain users could override all the ACLs in a web, without giving those users complete site-wide admin privileges. It does seem useful to have additive ACLs, but you would still need to edit every topic in the web, adding the +, to get the desired results.
So while this might be desirable to keep some backwards compatibility, it doesn't really solve the issue I've encountered.
- 06 Feb 2017
A preference setting
set to true / enabled, could make this a default behavior per the normal preference hierarchy. Another example for example, in the Usersweb, it might be reasonable to allow the group that "approves" registrations to have more generous access to user topics.
- 07 Feb 2017
In general the idea is not bad even though it doesn't really make ACLs more understandable. What people normally do is to add
. He might get more access than required but that this kind of problem didn't really arise in the real world as far as I've seen.
Adding this feature to the current ACL system might be easy. Yet I'd prefer to only
enable it via a configure switch if backwards compatibility to TWiki is a requirement.
I'd call it
given we already have
... and default to
- 07 Feb 2017
This is ready for evaluation for 2.2, in the Item14342
- 14 Mar 2017