List hier-acl users who can access the current page
Here is an exact description of the task this bounty is made for (see also MoinBounties for the general stuff): ...
See the corresponding Feature Request
Here's a repetition of the original ... if good ideas are suggested on the feature request page we can discuss adjusting this description accordingly:
Hier-acl is great, but having to remember who has access to each page is dicey.
This addition would make it easy: On pages where special hier-acl permissions are in effect, we can display a special Select box along with the other menu options.
Clicking that select box makes the box visible with this info:
WHO CAN SEE OR <blue>EDIT</blue> THIS PAGE? GROUPS: ___, ____ USERS: ___, ____ BUT NOT THESE USERS: ___, ____
The reusable function that calculated these permissions could have parameters to customize its behavior to suit that wiki ... for example,
- accessTypes: The types of access we care about: read, edit? (Each is displayed in a different color.)
- expandGroups: If true, list all users who have access - by virtue of their group membership or direct inclusion. This would be a longer list.
- displayForUsers: If this feature should only be displayed for certain logged-in users, this comma-delimited list of users won't be blank.
- displayForGroups: If this feature should only be displayed for logged-in users who are members of certain groups, this comma-delimited list of groups won't be blank
A note -- with hier-acl, the permissions cascade. For example, group1 +group2 -user3. We can handle the tougher minuses by listing them all as particular users in the "But not these users" line.
Optionally, a nice display trick would be to use an OPTGROUP select box to create a multi-level display - hovering over USERS shows the users, hovering over GROUPS shows the groups, hovering over the BUT NOT THESE USERS shows them.
Until the bounty is taken, anybody can add or remove his/her funding offer to/from this list:
- 100 USD, valid until 2006-04-15, Steve Barr (steve AT memetown DOT com)
Do you want to have hierachical ACLs in moin or mainly the possibility to see the actual ACLs?
We can assume the person already has the hier-acl patch installed. (Though it could easily work with traditional ACL as well for people who don't.) So the goal is to just display the result of the ACL's.
Example 1: suppose we're on a page called "Category/Subcategory/Pagename", and
- page Category has ACL "myGroup"
- page "Category/Subcategory" has ACL "+lindsayLohan,-britneySpears,yourGroup"
britneySpears is a member of group yourGroup, and LindsayLohan isn't a member of any group.
In that case, on page "Category/Subcategory/Pagename" we'd display the following access:
WHO CAN SEE OR <blue>EDIT</blue> THIS PAGE? GROUPS: myGroup, yourGroup USERS: lindsayLohan BUT NOT THESE USERS: britneySpears
(Mini-discussion that resulted in -britneySpears being ordered before yourGroup in that example. Presumably no longer applicable?)
This is incorrect. BritneySpears will be able to access the page regardless of the above ACLs. Please consult the documentation again.
The page HelpOnAccessControlLists explains this in the section "processing logic"
Example 2: Let's say that instead, page Category had ACL "myGroup", but page "Category/Subcategory" had ACL "-yourGroup", and page "Category/Subcategory/Pagename" had ACL "+bonJovi". Let's suppose membership of yourGroup includes users bonJovi and demiMoore. Then on page "Category/Subcategory/Pagename" we'd display the following access:
WHO CAN SEE OR <blue>EDIT</blue> THIS PAGE? GROUPS: myGroup BUT NOT THESE USERS: demiMoore
I am not sure if bonJovi cannot read the page - can you comment on it, ThomasWaldmann?
Example 3: Suppose we have a page called "MyPage" whose ACL is "yourGroup,cyndiLauper". if our expandGroups parameter is set to true, this feature would show the actual group members instead of the group names:
WHO CAN SEE OR <blue>EDIT</blue> THIS PAGE? USERS: bonJovi, cyndiLauper, demiMoore