Feature Proposal: Changing Access Permission


I am making a wiki for my Institute and find that it is really needed at a lot of places like mine to prevent important information to be misused.

Description and Documentation

There should be some way out in Foswiki such that no authenticated user (except the admin group) can edit the read/write permissions(for other users) of a topic/web but can edit the topics.

In simple terms, what I want from my Authenticated user is just to read/write/create the topics. I don't want to let him play with other variables such as Access Variables.


(Note: that this example is the opposite of the above.)

I set my permissions as in the web preferences for each web
* Set DENYWEBVIEW = nobody
* Set DENYWEBCHANGE = Users.Guest
* Set DENYWEBRENAME = Users.Guest
* Set ALLOWWEBRENAME = Users.AdminGroup
* Set ALLOWTOPICCHANGE = Users.AdminGroup
* Set ALLOWTOPICRENAME = Users.AdminGroup

Even then any authenticated user can change the permissions for the topic to which he has write access by simply writing

This way others cannot edit the topic.


It will allow a simple set of permissions to be used by a website developer. The user will have no access to the access variables which will make matters quite simple.



By using FINALPREFERENCES, or a similarly functioning FINALPERMISSIONS we give the foswiki admins the ability to set a collaboration policy for a web - and preventing users that have CHANGE permission from modifying that policy.

This works in either direction:

  1. Wiki style - set a web to always allow VIEW/CHANGE (useful in a workplace where you want to change the culture from hide info until you're completed)
  2. CMS style - permanently restrict VIEW/CHANGE to a certain group (useful for accounting, secrets, server details - pretty much anything where there is no way you want info to be leaked by accident)

Wiki style web

to prevent the over-riding of CHANGE permissions (thus anyone who is not guest will always be able to edit - even the WebPreferences topic....?) you would add the following to your WebPreferences:
* Set DENYWEBCHANGE = Users.Guest

CMS style web

to prevent the over-riding of CHANGE permissions (thus anyone who is not guest will always be able to edit - even the WebPreferences topic....?) you would add the following to your WebPreferences:
* Set ALLOWWEBCHANGE = Users.PressReleaseGroup

-- Contributors: AbhishekGupta, SvenDowideit - 02 May 2010


It is this kind of admin ideas that destroys wikis.

I am totally against such a limitation to the individual user. I'd rather loose a few potential users of Foswiki than destroy the wonderful soft security we have for all the rest of us.

If a user can edit a topic he should also be able to edit the access rights. If he cannot - he cannot protect confidencial information. And he needs an admin each time he needs to change access rights. This is the sort of feature that destroys collaboration instead of promoting it. If this is what you need get an over-engineered content management system instead. I know from personal experience from my work place how much these over-engineered access rights damage instead of help protecting. What happens in practical is that best case your users add information and just never bother to add any access rights leaving everything open. And worst case - they just don't bother to participate on the wiki. Adding this kind of all too admin controlled access rights have the exact opposite effect of what you think you get.

We are many with many years of actual experience of TWiki/Foswiki that know that the current access rights actually work very well in practical life. Also in corporations that need to protect information. But always remember, that Foswiki is basically a WIKI. Not a CMS. And the power that a Wiki gives is empowered collaboration. This is what makes Wikis stand out from all other Web 2.0 tools like CMSes. I know many feel that the application framework Foswiki has is tempting for building small database apps and that is cool in itself. I do this myself. But if we sell out on the Wiki qualities that Foswiki has then we may as well stop developing this tool. There are so many both paid and free CMS and DB tools on the market with webmaster syndrome tight access rights with very advanced rules and limits.

With the current access rights that Foswiki has you can protect all the application topics you build from occational fooling around, and you can set a web level protection for the access you want to give. You will not in practical life see users adding too loose additional rights. And if they do - the same users will also send the same confidencial information by email to anywhere ourside the organisation.

-- KennethLavrsen - 02 May 2010

From a technical standpoint, adding a new layer of access control (meta-ACLs?) is tricky, and if you truly wanted this feature then I actually suspect it would be wise for us to work on the bigger issues of out-of-band META:PREFs/Set vars, caching etc. first. Not to mention that new ACLs can be fraught with unforeseen consequences and complex interactions.

So, I also agree that it should not be a core feature, because as Kenneth said it's too easy to kill collaboration.

First idea: simply a beforeSaveHandler that checks if the about-to-be-saved revision has different ACLs to the existing rev.

If the user has modified the ACLs, then the save is aborted.

Such a plugin "should be pretty easy to do" (typical words from your average programmer :-).

-- PaulHarvey - 03 May 2010

I was talking to Abhishek on irc yesterday, and I have the feeling that Kenneth is quite strongly wrong. If you read the example (as opposed to Abhishek's real need) above, you will see that it would prevent topic siloing, by making it possible to set up a web to be specifically for collaboration.

eg. the web will require users to be registered and authenticated, but will prevent anyone from limiting EDITING, and similarly, VIEWING is un-restricted.

This is an extremely good way to enforce a collaboration policy on a web basis - and still allows for the recommended practice that information that should be protected goes into a separate web.

Abhishek and I initially expected to be able to use the FINALPREFERENCES setting - so imo the best solution would be to make that work, or to add a FINALPERMISSIONS that does the same thing for our current in topic PERMISSIONS system.

  1. killing a save is way too late - you do not want to kill collaboration by allowing a user to spend hours writing something, only to find they can't save.
  2. implementing this feature will no more kill collaboration than not implementing it - right now, any user can kill collaboration by preventing CHANGE on any random topic.
-- SvenDowideit - 03 May 2010

That is a good point, Sven. I have removed my concern. Although, I should add that, in "aborting" a save, I would hope that it could be done in a way that took you back to the editor without losing any work - to give the user an opportunity to restore any VIEW/CHANGE/COMMENT etc. ACLs.

-- PaulHarvey - 03 May 2010

I am actually not too deeply worried about a feature that prevents people from making tighter access rules. But such feature will be abused by admins to do the opposite. Ie. admins will set very tight access and require that only they can loosen up. I have seen this again and again in many different contexts. I have to write IT support tickets to have access rights changed on Windows shares which means in practical that we never do it. It is an invitation to none-wiki behaviour. And in all practical life it is not needed. A good set of web level rights will normally not be overwritten at topic level unless there is a good reason for it.

We introduced our (tm)wiki back in 2004 with the purpose of using it for an ISO9000 quality management system. We set it up so only predefined groups had edit access to the ISO procedures. It was a good success but after 4 years we could see that there was still 50% of employees that never cared to raise change requests for anything. So here in 2010 we have taken the step and removed all edit change rights and it means that people now bother to edit obvious mistakes. People like to see a result and they hate to ask others to do something because they assume - CORRECTLY - that it will not be done in any relevant future.

So my experience is that the less access rights - the better - for Wiki collaboration.

HOWEVER. We are also a business. And we have business secrets that we at least in the beginning has to be controlled. Giving the users the possibility to add ALLOWTOPICVIEW means that we also use the wiki for many other business purpuses and that would not be possible if people could not limit especially read access to groups and individuals for information that cannot be shared with everyone in the entire 70000 people company.

One silly admin should not be able to prevent good use of access rights because he at the moment of the installation of Foswiki cannot see all the other possibilities the tool gives his users. Ie cannot see beyond the initial reason to install Foswiki.

We that have worked with Foswiki as users for many years know the power of the tool. People that begin does not know. And especially system administrators who in practical life are often having educational backgrounds very different from their users, cannot understand the impact on the business. We see that with Windows access rights. Admins use all the features that are available and try to make everything shut and tight and end up making ticket systems to manage when the users want them changed. It is a hell. It is so fantastic that in Foswiki users can set access rights themselves. If 5 users have access to something they themselves can give access to a 6th person. On other systems you cannot and those are a pain to use where you have to spend days finding out who has rights to give access to certain areas. We have this hell in the Livelink CMS system we also use.

No thank you. I know how it is to have these features. I'd rather be without them. And I know at the end of the day it is best for 99% of our users that it remains like this. And the last 1% that cannot live with that. Well - Sad!

  1. -- KennethLavrsen - 04 May 2010
I have to second Kenneth here. For what my opinion is, this increased authority to admins is not good. Yes, some users may make mistakes or intentionnally block things. It's part of the game. But in the end, these are rare events, and explaining that user their mistake will solve the problem. The biggest advantage of wikis is that it empowers people, make them feel their effort is useful. Any feature going the opposite direction should be avoided, especially because a majority of admins want to "keep control". Please keep FUD out of wikis.

SvenDowideit says : right now, any user can kill collaboration by preventing CHANGE on any random topic. but think about how devastating this would be on the Main web : you would simply not be able to protect your home page ! Enough for many people to stop using the wiki at all.

-- ChristopheVermeulen - 05 May 2010

A missing core feature IMHO is a sensible way to query/report access controls present on a topic. I have a colleague running confluence who reckons that a 3rd-party plugin that was able to enumerate exactly which users were able to edit/view/etc. a topic was instrumental in increasing uptake; Set ALLOWTOPICVIEW is all well and good, but most collaborators don't "trust" it - some widget that confirms or clarifies their understanding of the ACL situation is still missing from Foswiki.

In my wiki, it's been enough to add some CSS that sets the background colour a horrible pink when WikiGuest AND the default staff group is denied; that way users are confident the page is non-public.

-- PaulHarvey - 05 May 2010

I partly agree with Kenneth, but the agreement disappears because of the following two reasons:

1) There are enough bad elements in the society from which the admin might have genuine fears. For example, a spammer can register himself, advertise his business and restrict the editing rights to himself, by one line of code. Unless and until the admin is not able to realize the change the spam is there in the group. Another example, I may deny Kenneth his right to write for this topic. Though, others can rectify it, but still it is something that everyone should agree is wrong.

2) Secondly, my users have quite a rights. They can edit any topic by their will. In no case we can give them all the permissions. There has to be a boundary somewhere. What is important is to decide, where that boundary lies.

-- AbhishekGupta - 5 May 2010

A small modification to the basic idea, can perhaps address lot of concerns sited above.

Currently, the right for editing permissions of a page is same as the right for editing the page. If we could separate these 2 rights for the whole wiki, then I think lots of concerns above can be settled.

So, then we will have 6 rights associated with a topic.

  1. Read - Who all can read this page.
  2. Write - Who all write this page.
  3. Rename - Who all can rename this page.
  4. Read permission Change - Who all can change the permissions for reading.
  5. Write Permission Change - Who all can change the permissions for writing.
  6. Rename Permission Change - Who all can change the permissions for renaming.
The person who creates the topic, gets all these rights(along with the admin). Now, this person has the complete control over what he wants to do with this topic. He is in some sense the admin for this topic. He can add more admins (by giving them permission change permissions) and more normal users(by giving them only non permission change permissions).

If we have such a feature, then it is not that the all permission control is in hands of the admin only. It will also, give people control over what happens to their own topics/contributions.

-- SaurabhGupta - 06 May 2010

A quick note to say: a wiki that allows public registrations such as mine, uses a couple of tricks to avoid spammers:

  • None of the webs, anywhere, allow a newly registered account to edit anything. They must at minimum be a member of the "confirmed" group (users who have been confirmed as non-spammers).
  • The NewUserTemplate has an ALLOWTOPICVIEW = ConfirmedGroup, TheSpammer and ALLOWTOPICCHANGE = ConfirmedGroup. This prevents the user from planting spam on his own user topic, or allowing search engines to crawl any links that were planted during registration in the comments field.
Another quick note to consider: you've listed the default access controls possible in a standard Foswiki, but custom ACLs may be provided by plugins. For example, there is ALLOWTOPICCOMMENT, provided by MetaCommentPlugin.

Thinking about all of this: I think it would be less of an issue for there to be no ACLs on ACLs, if we had the following:

  • Easier moderation workflow - SiteChanges may or may not be adequate, opinions?
  • Quickly see a list of all the edits a user has ever done, building on the work recently mentioned in the foswiki-discuss ML?
  • Better visualisation/confirmation/clarification of the ACLs in effect on a given topic.
I suspect that ACLs on ACLs would be a useful feature in some cases; I am just wondering, if we had the above three points addressed more fully in the standard Foswiki distribution, would we still need them? Or are your wiki's users so hostile that the moderation workload would always be too high? Will your wiki never have a large enough group of active moderators cleaning things up?

-- PaulHarvey - 06 May 2010

There are bad elements in society. Yes. But 99.9999% are good people. The cost of preventing collaboration among the good people is too high just to save the admin the few hours of work per month to remove spam.

In public Foswiki's outside a firewall the problem is spam. Spammers have been able to abuse access rights for years. Very few actually do because they know the effect is very small. Any sain installer of Foswiki knows that he needs a reasonable group of people in the Admin Group to fight spam and help people. The minute you are 3-10 people in the admin group the practical problem is gone and spam survives very briefly.

Those Foswiki sites that keep spam have it regardless of access rights. They are sites that noone care for. Foswiki's set up and never really used for anything.

Wiki Spam is annoying. But it has a very little cost to an organisation (unlike email spam which is very expensive). Wiki spam is about planting a few links to your site to get higher Google ranking. You have to weigh the cost of this annoyance up against the cost of people not being able to collaborate. Add to this the fact that public Wikis normally never have confidential information in them. They are normally about sharing - not hiding.

Most Foswiki's are behind Firewalls. The primary target group for Foswiki (and the old project) is collaboration within businesses. You do not have spam behind a firewall.

The suggested permission changes significantly limit the possibilies for users to control access rights. Users will constantly find themselves looking for the original topic creator to be given access rights. In reality it is the admins that end up with most requests to be given rights. You see a monster that is not there. We that have had a Foswiki/(tm)wiki in a business context for many years know. We also know the problems with have with other systems that have exactly the features you are suggesting. And the conclusion is - thank God for Foswiki and its soft security.

There are a few common problems with access rights we need to address maybe in Foswiki 2.0.

  • Users can by accident set access rights so they cannot edit a topic themselves. This happens when they misspell their own name or a group name in an ALLOWTOPICCHANGE. We need to have a warning when you save a topic and the result will be that you shoot yourself in the foot. It could be a warning window that ask if the access right should be removed before the save, or it could be that anyone saving a topic can always edit it until the lease expires combined with a warning.
  • A site wide setting that can set a minimum site level access right so that you can set things like
    • Noone can give read access to guests for sites where you want to ensure people are authenticated before they can see anything. Ie you have to be an employee.
    • Noone can edit any topic unless they are member of specific groups. This addresses the public sites where an admin will like to approve new users.
But access rights to set permissions. That I cannot support. The cost of having this feature is much higher than the gain.

-- KennethLavrsen - 07 May 2010

Having a set of six rights as Saurabh suggests is really a brilliant solution to the problem. Not every site on the web is maintained by a large enough group to moderate each and every item that is put on the web. Having such a set of rights will prove it much easier for a site admin to have a complete control over the site and with a lesser number of people.

The set of six right form an exhaustive set of rights that may be given to any site admin. Also, I would like to object Kenneth when he says the site admin may misuse his set of rights. First of all, when we can assume that the 99.999% people using the website will be good and rest of them will be taken cared by the website moderators I think it won't be difficult to assume that the site administrator is one of those good people and will take good care of his website.

And about the private pages that a user may want to create for a specific group of people, I would say that there are a lot of cases (mine is one of them too) where it is much more harmful for the website to allow its users to do so rather than when they are not allowed.

The set of rights are quite flexible in itself and there is nothing like breaking the rules of collaboration for a wiki. So, I would like to request you to once again think over the matter and have a plugin for this or have this as an optional/compulsary feature in the Foswiki 2.0 . Having such a set of rights will make the Foswiki more flexible, controllable and more developer friendly.

-- AbhishekGupta - 17 May 2010

There is religion and there is experience. The latter is based on FACTS and that is the only thing that counts for me. The experience from other tools with these "admin friendly" is that admins abuse their power and put too strict access controls. I have been suffering these power hungry sys admins for more than 20 years and one of the most important things I LOVE about Foswiki ( and (tm)wiki ) is that admins CANNOT impose this kind of restrictions. All other systems we have suffer from access rights restriction hell.

In in a company like the one I work for most users are people with a 4-6 year university degree and we are held down by a few geeks with a 0-2 year computer training who's only power is the admin password. They do not understand or care about collaboration. All they care about is minimizing their own work effort and enforcing their narrow minded view of security. The Wiki's were invented to challenge the web master syndrome. The "Wiki Way" has the soft security as its MAIN QUALITY. The 100% audit trail combined with no way to erase previous versions is the security you need in an intranet wiki. Anything else is non-wiki. Yes you can use Foswiki as a sys admin controlled content management system. But then go for a content management system. We do not make any money on Foswiki. It is not important that as many people as possible install Foswiki. Chose something else if it is not a wiki you want.

"I think it won't be difficult to assume that the site administrator is one of those good people and will take good care of his website". Well. It is not the administrators website. It is the users website. The administrator is supposed to serve as an expert. Not as a God. The best admins are the ones that use Foswiki themselves daily. I am one of them. I know that less access restrictions means more collaboration.

I wonder if you guys asking for this have used Foswiki or (tm)wiki over a period of years, or you are considering introducing it and just want to have the same controls as you are used to from your previous systems.

-- KennethLavrsen - 17 May 2010

I want to ask one last thing. If somebody restrict any view or edit rights that is a say (BadAction in general) the only way I can deduce for the site moderators/admin is to visit that page and undo the BadAction. In general, how are they supposed to know that some BadAction has been taken place and should be corrected. Are they suppose to visit or review all the topics on a regular basis. Or is there any other mechanism to ease this out. One that I can think of is Report Abuse button after the website. But, even this is not very efficient.

-- AbhishekGupta - 20 May 2010

Changing this to a DiscardedProposal. There is no committed developer, and there seems to be general concensus that this isn't a good idea.

-- GeorgeClark - 13 Nov 2015
Topic revision: r18 - 03 Nov 2015, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy