Tags:
create new tag
, view all tags

Feature Proposal: More Topic Actions: Change Privileges

Motivation

I realize this is contrary to the Wiki philosophy but, one of the things people want to do, often, is to lock a web or page against viewing or editing by other people. And, according to our Company TWIki admins, one of the more common support requests comes from people who have make a typo while trying to change privs and locked themselves out of their page.

I would like to see some better support from TWIki for setting privs, preferably as a section in the More Topic Actions page.

For example, we could have a set of check boxes that would let people allow or deny TOPICVIEW or TOPICCHANGE. TWiki would automatically include the current user in the "ALLOW" list (the same way that new groups are created with the creting user as a membet of the group.

Providing an easier Way to set privs would obviate the need for the user to remember the command syntax and reduce the chance of typos that cause trouble for sysadmins.

-- TWiki:Main/VickiBrown - 22 Dec 2007

Any thoughts on the TWiki:Plugins.WebPermissionsPlugin?

-- TWiki:Main.SteffenPoulsen - 22 Dec 2007

Description and Documentation

This was filed as http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item5167

discussion started. Closed as "No Action required"

Reopening here. We should not lose the discussion that was started.

Examples

Impact

WhatDoesItAffect: Usability

Implementation

-- Contributors: VickiBrown - 27 Dec 2007

Discussion

Steffen: TWiki:Plugins.WebPermissionsPlugin looks... interesting... but

  1. that's for an entire web; I'd like something on a topic-by-topic basis
  2. That's a plugin, which requires an admin to install it.

I'm looking for something that helps the user do something the user is already doing - changing the privs on a given topic - in a way that tries to prevent accidents.

I think we need built-in TWiki support for making it easier for user's to change the privs on a single topic. They do it now and they make mistakes. Requiring a plugin means the plugin won't be there and we'll keep having the same accident-prone interface we have now.

-- VickiBrown - 27 Dec 2007

If the plugin is part of the standard distribution (like comment, edittable etc), it wouldn't be an issue. I have to say that I like the idea as I have had to fix broken perms as well.

Now we just need to extend the plugin to cover pages as well.

-- JohnRouillard - 27 Dec 2007

I know the problem of people shutting themselves out. And I also know the problem of people setting access rights wrong so they think they protected the topic but in reality they missed a space or forgot to remove a little #.

Today we have the More topic actions -> Edit Settings feature where people can add any settings including access rights settings.

BUT

It is a geek feature created to make mistakes. The only valid syntax in Edit Settings is to make bullets that set a TWiki variable. One space too few and it does not work and does not get stored as meta data.

In my view the Edit Settings screen should contain a form with variables and a text entry field like when you edit a topic form.

And DENYTOPICVIEW, DENYTOPICCHANGE, ALLOWTOPICVIEW and ALLOWTOPICCHANGE should always be there by default but only be stored as meta when set to non empty and not white space only.

And then you should be able to add and remove other variables you may want in the topic.

It would also be a good feature if when saving the settings, you would be warned if you try to set the ALLOWTOPICXXX to not include yourself. Ie. your name is not there or no group which you are a member of. The warning should give you the chance to dismiss the saving and get you back in the edit settings mode.

If implemented I would like to have a guide text above or below the ALLOW/DENY section that ask the user not to set access rights unless there is a good business reason to do it because access rights in general limit the wikiness of a wiki. Some people not used to wikis add access rights on "autopilot" for no good reason and if it becomes easier it also becomes more frequent to see these autopilot people.

The help text could also very well list the default access right given at web level that exists so people do not add access rights that are already there at web level.

-- KennethLavrsen - 27 Dec 2007

I like the proposed feature. I prefer to keep it separate from general topic settings. ClearSpace has a very nice approach to ACL handling per topic. It has got two sections to maniplulate ACLs. The first is listing standard use cases how to lock/unlock a topic, the second is for experts giving finegrained control. That's enough of a GUI to be grasped by a user. I will give you a screenshot of this dialog in ClearSpace soon.

I agree with Kenneth in all other aspects. Edit-Preferences can hardly be done worse.

-- MichaelDaum - 28 Dec 2007

I am 100% OK with having ACLs seperate.

But I do not see how we can have flexible ACLs only with checkboxes. A very normal way to set access rights is to set ALLOWXXXX = list of groups. And you can have hundreds of groups. It is important to discourage the use of single names because in any organisation roles/jobs change all the time and then you end up with 100s of topics with the wrong person in the ACL.

-- KennethLavrsen - 28 Dec 2007

I think we can separate how preferences and ACLs are stored from how they are set. Let me try to mock up what I mean:

Manage Collaboration

Users who may edit:

Select

Users who may view:

Select

   

The actual rules are then stored into the topic meta-data as usual.

-- MichaelDaum - 28 Dec 2007

How would you show overriding settings (that are currently stored in WebPreferences)?

-- ArthurClemens - 28 Dec 2007

Hm, how about adding a row "Default (as stored in WebPreferences)"?

-- MichaelDaum - 28 Dec 2007

Some values may have been set at a higher level, leaving out more specific choices.

-- ArthurClemens - 28 Dec 2007

Yes, I see. Whereas we can compute rule-sets from those informal selections as outlined above, we can't easily do the reverse which would be needed to set intelligent default values in the GUI. However, we can refer to it choosing "Default", which effectively removes all topic-level ACLs. Any other selection can be implemented on topic-level thus overriding any other ACL on a higher level.

The reason to have these informal selections is to make things less geeky, while sacrificing some corner cases. If we find some cases that do make sense and are expressible informally, we should add them to the GUI. This approach can fail, if that becomes too much of a stretch and we end up with a non-comprehensible interface again.

-- MichaelDaum - 28 Dec 2007

TWiki:Plugins.WebPermissionsPlugin is not just per web. It already contains a UI (accessed from each topic's more topic actions link) to change that topic's view and change permsissions. Changing the user interface to match that suggested above should be a realitivly trivial UI change to TWiki:Plugins.WebPermissionsPlugin.

-- SvenDowideit - 29 Dec 2007

Very good discussions here. We need an easier way to set ACL in order to move TWiki from the geek tool to mainstream.

On settings defined at higher level, I suggest to add a new radio button: "Use default setting defined at higher level", possibly showing current value.

-- PeterThoeny - 02 Jan 2008

The existing UI from the already released TWiki:Plugins.WebPermissionsPlugin is customisable, as the output HTML is contained in webpermissionsplugin.topicjavascript.tmpl and webpermissionsplugin.topichtml.tmpl

So Michael's proposed UI is already possible. As is Peter's rather useful suggestion for a user friendly 'remove local topic permissions'.

Manage Collaboration

All Users and Groups

Editors

Viewers

       

-- SvenDowideit - 10 Jan 2008

That's pretty complicated, IMHO. The other proposal was using an informal way to describe ways of collaboration. These are then mapped onto real ACLs by the backend. So that's a fundamental different to WebPermissionsPlugin. At least, WebPermissionsPlugin would have to be extended to be able to do the mapping.

-- MichaelDaum - 10 Jan 2008

My point is that your proposed UI can trivially be implemented by creating 2 tmpl files in WebPermissionsPlugin. WebPermissionsPlugin can already do the mapping you propose.

-- SvenDowideit - 11 Jan 2008

Ok, it looks as if it could be done using this plugin. The logic to map informal to real ACLs will then have to be done in javascript by setting the appropriate rule sets in the urlparams (topicviewers, topiceditors, ...) before the save is submitted. Is that right?

-- MichaelDaum - 11 Jan 2008

That'd be the most trivial y - Though the ones that are listed right now:

  • Anyone - requires no mapping
  • Registered users - I presume this is the same as NOT TWikiGuest
  • Just TWikiGuest - no mapping needed
  • Specific users/groups - would need some JS to activate a UI
  • Use settings from a higher level - needs no mapping either.

From memory, the 'set' operation is a POST using a comma seperated list of users/groups.

-- SvenDowideit - 11 Jan 2008

Good! I can create the templates and add them to the WebPermisionsPlugin.

So remaining question: what will be the relation of the core engine to the WebPermissionsPlugin? Do we close this FeatureRequest with a state "will be added do plugin X"?

-- MichaelDaum - 11 Jan 2008

Personally I think we should use the existing code to allow us to discuss and evaluate where we want to go.... Then we are in a place to just add it to the core, either as another default plugin, or natively. I suspect that the refactorings for 5.0 will simplify the final implementation.

-- SvenDowideit - 11 Jan 2008

Edit | Attach | Watch | Print version | History: r20 < r19 < r18 < r17 < r16 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r20 - 2008-10-19 - MichaelDaum
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.