Feature Proposal: It should be easier to get a definitive overview of the Access Controls present on a given topic.

Motivation

Contributors in private/protected areas have in the past been burnt by misunderstanding the access control situation in their web or individual topics.

Even those that haven't been burnt, are given better piece of mind and are more likely to use the wiki if they can see a good accurate overview of who can and can't view/change their topics.

Also, WebPermissionsPlugin is a good start for users to add colleagues into a protected topic by themselves, but could do with some improvements.

Description and Documentation

ShowAccessPlugin was a good start for our installation. I modified it to use _getACLs in WebPermissionsPlugin::Core, so that it would properly display any ACLs embedded in topic metadata via that plugin.

I also modified it to generate a list of users that can change (TWiki release version only shows users that can view).

Really, this is still not entirely everything I'd like to do with ACLs: it'd be very useful to render a table of users with their profile metadata where desired. Examples soon...

Examples

With some new tag handlers that would take a format="" string, and maybe some work on the %USERINFO{}% handler, I'd like to build a topic for our users such as this:

Assume in Development/WebPreferences:

• #Set ALLOWWEBVIEW = HomerSimpson, EverybodyLikesNedFlanders
• #Set ALLOWWEBCHANGE = EnemiesOfChaos

---

Access Controls

For this web (Development), default permissions are as follows:

• Who can view? Users: HomerSimpson and Members of: EverybodyLikesNedFlanders
• Who can change? Users: AmbassadorKosh

For QueryAccessControls:

User	View	Change	Instititution	Via groups
AmbassadorKosh	YES	YES	Vorlon Empire	EnemiesOfChaos, EverybodyLikesNedFlanders
NedFlanders	YES	NO	The Nedstitution	EverybodyLikesNedFlanders
HomerSimpson	YES	NO	Duffaholics Anonymous	AgentOfChaos, DuffFans

---

Impact

As mentioned by CDot, this work could drastically degrade performance on sites with many users or auth schemes other than the built-in arrangements (such as LDAP, Shibboleth, etc). The site I maintain has 300 users and already if somebody queries the Main page (which everybody can view, so 300 records returned), there's a 6-10 second wait at the server (1GB/1GHz VM host running a few other things).

CDot had some ideas for caching ACLs (extending DBCacheContrib?) which could alleviate the problem somewhat (What about webcrawlers that will try to hit every single "view access controls" button that might be in a site's template?). Maybe this sort of functionality should limit itself to the first 100 results (the usage scenarios I'm thinking of are for small groups of say 1 to 20 paranoid contributors to check that their small group of colleagues can view or change some topics anyway).

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: PaulHarvey - 24 Jun 2009

Discussion

I am still working on this topic... will document the new taghandlers I have in mind and the UI tweaks for WebPermissionsPlugin. -- PaulHarvey - 24 Jun 2009

Hey there. Here's a screenshot of the upcoming NatEditPlugin that makes use of SetVariablePlugin to edit permission settings of a topic during edit:

While that's only on a per topic base, it shows how to ease setting permissions substantially by informal description of permissions to be set behind the scene. The list of rules for view and change roughly outline the most frequently use cases, afaik.

-- MichaelDaum - 24 Jun 2009

I've been working on a similar thing. I've updated WebPermissionsPlugin for topic ACLs so that it correctly takes any permissions inherited from the web into account as well instead of just the settings in the topic. I've also created a 'simple options' page with the options that you can see in the screenshot below (plus, when ALLOWWEBVIEW is set, there is a Group read/write access option). I don't have the predictive username input field, yet The Custom ACLs page is the one you already know from WebPermissionsPlugin for topic ACLs.

The only 'issue' is that it is written in (tm)wiki for now (until I've got the time to migrate I'm still doing development on twiki 4.2.3 yeah, yeah, I know, I never will have the time so just do it!). I can attach the files to the WebPermissionsPlugin dev topic and you can have a look.

-- DavidPatterson - 24 Jun 2009

OK, the WebPermissionsPlugin hasn't been released on f.o yet so there's no dev topic. You can find a ported version (completed?) of it in the svn with a rest handler upgrade to the Web Permissions table.

Here is a zip of my updated files of the (tm)wiki version of WebPermissionsPlugin. I've only updated the topic side of things so there are no overlaps apart from the code which commits the changes to the web ACLs (to be found in both versions under the comment "# Commit changes to ACLs").

-- DavidPatterson - 24 Jun 2009

It's great that you guys are talking to each other. One small idea; stop throwing ideas over the wall at each other, and work out how you can collaborate. It sounds me highly likely that there is some common support required on the server (judging from the remarks above about various plugins). Surely there's an opportunity there for some mutual support?

-- CrawfordCurrie - 25 Jun 2009

Good. I'll use DavidPatterson's code as a starting point; interested in the resthandler modifications. I would still like to merge the new taghandlers that would allow us to clearly annunciate lists of users that can perform a given action; and it should be easier than it is to check whether a given user is able to perform a given action without TWiki:Plugins.ShowAccessPlugin.

I don't have time to play around with filter-as-you-type functionality just yet, but will certainly be in my mind when looking at the rest interface.

-- PaulHarvey - 26 Jun 2009

A date in the future for the commitment sort of confuses the application for proposals. I have removed the date.

-- KennethLavrsen - 03 Aug 2009

I think this will be easier if we have a QueryCustomCollections mechanism, Ie. something like:

%QUERY{"users[topic='%WEB%.%TOPIC%' AND allowtopicchange]"}%

-- PaulHarvey - 07 Nov 2010