Tags:
create new tag
, view all tags
Hi folks:

How about 2 new access control variables:

  • DENYWEBCREATE
  • ALLOWWEBCREATE

These would be similar to the DENYWEBCHANGE/ALLOWWEBCHANGE. except that it would deny/allow edit access for only new topics.

This would permit creation of a new page in the twiki main web by the registration program, but deny creation of a new page in the main web by clicking on an uncreated TWikiWord in the user's home page or typing a new topic in the go box on the main web.

There are a couple of articles that relate to this, I just can't seem to come up with the proper search string to find the primary one.

It mentioned problem with users creating new pages in the main web because they didn't realize how the TWikiWords related. I can understand that because I created just such a page in this TWiki web just after I registered, and of course I can't move it since I don't have rights to do that in the main web. With these vars, I would be blocked when trying to create these new pages, but I would still be able to change my homepage.

The other (WikiAccesForScripts) was talking about access rights for scripts. In this case the registration script could be seen as having "create" rights even though the user doesn't.

I don't think this will be hard to do, and I will have a go at it if people think its worthwhile.

Quips, comments, evasions, questions or answers?

-- JohnRouillard - 24 Nov 2001

Sounds like a good idea. I particularly want to prevent people creating Bogus users just by adding topics in the Main web.

-- MartinCleaver - 26 Nov 2001

I think we could do with this on TWikiDotOrg - Peter told me that the TWikiAdminGroup waste a lot of time cleaning up after people create bogus entries in the Main and sometimes TWiki webs.

-- MartinCleaver - 16 Jul 2003

Man talking about losing a thread. I saw the topic name and said "Oh great more variables. I wonder what this one is for?" Then in reading this topic, I said to myself, yeah that is useful. Then I got to the sig line and realized THAT I WROTE IT 8-).

Yup. I still think this is a good idea even 1.5 years later. I don't have an up to date twiki operational to attempt to do the changes, so somebody else will have to write it I'm afraid.

-- JohnRouillard - 20 Jul 2003

It's been quite some time since this issue was raised, but I have a real simple solution. (See attached). A simple patch to TWiki/UI/Save.pm allows for {ALLOW,DENY}WEBCREATE and {ALLOW,DENY}TOPICCREATE.

Semantics:

ALLOWWEBCREATE
These users or groups can create new topics, no one else can.
DENYWEBCREATE
These users or groups cannot create new topics, but everyone else can.
ALLOWTOPICCREATE
(Template topics only) New topics based on a template topic containing this setting are allowed.
DENYTOPICCREATE
(Template topics only) Not very useful, but it prevents the listed users and groups from using that template to make new topics. (Kind of silly, since they could just make a new template exactly like the existing one and then generate pages from that, only without the ACL... this is a "feature" that is a result of the simplicty of the code change)

Generally speaking you use * Set ALLOWWEBCREATE = Main.MyAdminsGroup, Main.MyContentManagersGroup and/or * Set DENYWEBCREATE = Main.RestrictedGroup. Then you * Set ALLOWTOPICCREATE = Main.FormFillerOuttersGroup on any templates with forms you want people to otherwise be able to fill out.

-- NeilRG - 08 Mar 2007

This looks like a useful enhancement, thanks Neil for sharing! I added this to TWikiFeature04x02 to start the proposal process. (We do not yet have a TWiki tracker ready.)

-- PeterThoeny - 08 Mar 2007

ALLOWWEBCREATE seems like a misleading name - it suggests that these users are allowed to Create a new Web

-- SvenDowideit - 09 Mar 2007

I find that this proposal

  • Agree with Sven that the name is misleading. I also intuitively see it as allowing to create webs.
  • It adds another complexity to access rights. It is complicated enough already.
  • It is just another webmaster syndrome feature that allows Mordac The Preventer Of Information Services to put restrictions on the use of TWIki and suppress innovation. Limiting that people can only edit pages but not create new. That is so non-wiki. It is what I have been fighting for years and I would hate to have this feature in TWiki.
  • Why should people suddenly not be able to create topics based on another template? No no template? Too creative? Afraid that people may get ideas. This is exactly the kind of feature that limits the potential of TWiki. Enable and encourage people to use templates by making structure and cool TWiki applications instead of limiting people.

I would rather focus on making the access rights we have easier to use than to add more complexity, more feature interactions, and on top of that a step away from being a structured wiki to being just another content management system.

My KennethLavrsen topic says better where I am coming from.

-- KennethLavrsen - 09 Mar 2007

Right now, if you examine the logic that checkAccessPermission uses, it's pretty naive. This is why the "weird" name (ALLOWWEBCREATE), because checkAccessPermissions processes requests of (context, mode), where as it recurses from the topic and up the webs, it is looking for ALLOW/DENY(WEB/TOPIC).$mode In this case, $mode = 'CREATE' as to differentiate from 'CHANGE'

The main reason for this ability is to have webs that are used for structured data collection; where spurious topics could foul up/slow down search expressions. I needed this for a wiki application, and the change seemed innocuous, so I submitted it here.

And also, sometimes Mordac the Preventer of Confusing End Users doesn't want the user accidentally creating orphaned topics or creating forms that don't have the enabling template-carrying topic attached. Sometimes we actually create specialized templates for view/edit pages...

Anyway. No one has to advertise it.

And it's not complex. If you enable it on a web, it can restrict topic creation. At the point the user is expected to create Sets on templates that carry the ALLOWs (or narrow DENYs).

-- NeilRG - 10 Mar 2007

You are using exactly the arguments that I am so much against.

You talk about "confused end users" and that you want to prevent them from being confused by limiting what they can do.

Your users are in general smarter than you! Yes. I am not trying to offend you. My users are smarter then me also. It is a fact of life. 99% of your users will not create topics in your web or creating/changing forms breaking your application because they are confused. They do it to improve something that they feel is not working for their needs. And soon you will see new applications grow as they read the documents and experiment. But if you behave like Mordac and do not allow them anything then they will innovate nothing.

I am sure you have seen a few examples of the 1% that goof things. But can't you live with that?

You are doing the what system administrators have done for years and what applications like TWiki has been trying - very successfully - to change in an almost revolutionary way. Don't destroy what is the main strength of TWiki!

We are not going to put features in TWiki core and not advertise it. On the contrary we will always document every feature so that all users - not just the admin - can use the them. So we have to take great care when we add features. Especially when the features are disablers instead of enablers to the wiki idea.

Right now we have the access rights that people need to secure data so that confidential data cannot be read by people that are not allowed and so people - as an exception can put write access restrictions on webs and topics. Something which is mainly meant for public Internet sites.

You are trying to use TWiki for specific closed applications and I will not support this proposal because it is

  • anti wiki
  • adds an extra layer of complexity to access rights
  • not necessary

You will learn that if you create your TWiki Application well, it will be an exception that people create orphan topics or destroy anything. In 99% of the cases what they do is use the application as it is designed and if they change it - it is because the application does not fulfill their current requirements.

Organizations change all the time and applications are always falling behind. Allowing your users to alter the application and create new extensions is a strength not a threat. If a user creates a topic based on a template and then create a new topic from a WikiWord to explain stuff that the template does not support then that is a strength - not a flaw. And if your searches are screwed up because of it then fix them when it happens, and try up front to make them strong.

If you look at my publicly available Motion site

http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

Here users are not trained in using TWiki. It is a public site where anyone can register. The site consists of 5 simple main applications: Support requests, Bug Reports, Feature Requests, Submission of Patches, and Related Projects. Besides this there is documentation called the Motion Guide which consists of round 200 topics and maybe round 30 special purpose topics.

It has existed since October 2004 and has 900 registered users. From the beginning the WebHome has been structured as you see it. From the beginning the new users have been guided by simple web applications. Only 7 topics have ALLOWTOPICCHANGE. And that includes WebPreferences, The left bar because it was spammed all the time, and the GPL topic. If there was no spam I would probably not have locked a single topic other than the GPL topic which is locked for legal reasons.

And my experience is that the users use the application forms 99% of the time creating topics using the forms and asking their questions, reporting bugs etc etc without destroying anything. If you exclude spam fighting I may have to fix silly editing about once every 3 months. But the gain is that my regular users improve the application, add new topics to the Motion web that are very useful, and make the project a living evolving project and that is much better.

So quit the "Mordac the Preventer" role and take the "Neil the Enabler" role and live with having to occasionally having to fix mistakes. Delegate the correction job by involving more super users and make sure that someone takes the task to keep the important index and navigation topics clean and up to date. THAT is essential.

-- KennethLavrsen - 10 Mar 2007

I'm not dense. I know you have ideological reasons against this simple change. But TWiki is just technology with different end uses. It is a really, really, really flexible templating and transformation engine sitting on top of version control. TWiki application development is a new and developing field. You would like that every TWiki application look and feel like a normal TWiki, but augmented. You loathe when features are hidden or the interface streamlined.

But that is exactly what TWiki is designed to do. That is exactly what some people want (or think they want) and some of us are not in the position to change their attitudes.

Some people do not choose TWiki because it is a wiki! They choose it because it's a multi-user participatory CMS written in Perl, using no database, with a templating engine, etc. It's not just a wiki, it's a whatever-the-end-users-want-it-to-be. Never, never, never would you want to prevent another potential install. You'd be stunting the platform.

We would like to deploy TWiki for everything else it is able to do that is wiki-like and collaborative. Maybe one day when the users who use the streamlined system need something more freeform, the choice of an unrestricted TWiki will seem sensible and natural, and you can say you have admins who know how to use it.

But in the meanwhile it needs the ability now to control topic creation to prevent application webs from overtly breaking.

On the project that I was last involved with that required this modification, they were essentially paying me to write a series of extremely complicated %SEARCH and %IF expressions. I assure you, none of my end users have the time nor inclination to pick them apart and make additional search pages that handled new formats; that's why the gave me project hours.

And we don't factor in time for people to monitor and look for topics that are not formatted correctly for the magic to work. I spent 15 minutes on a bit of Save.pm that would guarantee that it wouldn't be necessary in the first place.

And Motion's main site is NOT the best example. Sure, it may be public, but consider the audience. You have to be interested in the software to navigate to the site in the first place. It is open source software, so you may want to add your insights or feedback, so you will want to put in effort to use the features the website offers to make your observations noticed by all parties. So of course the people who interact with it are going to make an effort to use Wiki best practices, they are self-motivated. They are not being forced to use the website through the course of their job or anything! These are the people you need to worry about. The ones that get frustrated when anything requires more than a few steps and might try to circumvent the system or misunderstand the very simple task they've been asked to do.

You might say: Don't use a wiki for that. I say: Why the hell not? Where do people get off and say what their product should or should not be used for?

It'd be different if we were talking about MediaWiki, which is highly optimized to be a wiki, with a strong database model and related infrastructure to that end, and shoehorning other things on top of it is kinda silly.

-- NeilRG - 12 Mar 2007

By the way Kenneth, I used motion in the last project I did. Really nice bit of software. I actually ended up using the vloopback kernel modules extensively and made some changes and it was all pretty wild.

TWiki was a good and natural choice for the documentation site. It was very helpful. Off Topic. but funny you should bring it up.

-- NeilRG - 12 Mar 2007

Everybody: Please give some slack to new folks. We should try hard to recruit new developers, and give helpful support until they are up to speed on how we operate.

Neil provided a patch for (ALLOW/DENY)CREATE. He had an "itching factor" to create this enhancement for a very specific TWikiApplication, and he generously offers this to the TWikiCommunity at large. Personally I think this feature is small, useful for specific needs, and out of the way if not needed. Feature like this allows WikiChampions to make the system easier for end users. (Yes, there are different types of end users. There are technical folks at Motion and on twiki.org where there is a lesser need to hide things; Neil's example is useful for sites with non technical end users who simply need to fill out forms.)

-- PeterThoeny - 13 Mar 2007

I am not trying to scare away new users. But I am trying to protect the idea behind wikis. Implementing this feature means it will be used heavily by Mordac. Such a feature can never be made out of the way. Unless it can be disabled in configure and then not shown in the access rights docs. Or implemented as extension. I still do not believe this feature is necessary as long as the basic Web Application is well written and guide people to create topics using forms.

My users on the Motion TWiki site are not that technical - I tell you. 99% of them open a bug report or a support request. Only the very regular users try to create new topics outside these applications.

What I am afraid of is two things to say it short.

  • I am afraid well meaning traditionally minded champions will "protect" their users by heavily using this feature to limit the use of the TWiki to ONE or FEW fixed applications. Good bye wiki. Good bye innovation. Good bye evolution. Good bye collaboration. Hello web master.
  • I am afraid that one extra layer on the access rights feature set will make access rights even more difficult to understand and more difficult to later make more user friendly and code efficient.

I really want the rest of the community to think very carefully about this feature before you vote for it.

-- KennethLavrsen - 13 Mar 2007

If this is a small specifically targeted feature, doesn't that mean it should be in a Plugin? I can think of a few different ways to implement it without changing the core.

More interesting to me was that NeilRG used as his reason for need, that he was developing a large number of complex TML's. There might be an even easier way to acheive the saftey he needs - I tend to put things like this into a Templates or Applications web, that is secured to allow the WikiChampions to edit. Then, when you use them, you're just INCLUDEing an application topic.

Mind you, that still leaves the Main web open, but I often hide that totally.

-- SvenDowideit - 13 Mar 2007

I thought this might come back to bite us. ALLOWCREATE is actually ALLOWCHANGE on the container.

Think of it this way. TWiki is a hierarchical filesystem, with a / level where root level webs exist, then subwebs and topics that correlate to subdirectories and plain files as appropriate. At any level you specify who can change objects at lower levels. So, let's say I specify ALLOWROOTCHANGE at the root level. That reads onto the top level webs and constrains who can CHANGE those webs i.e. create sub-webs and topics within them. Then, in each web, there is ALLOWWEBCHANGE which specifies who can CHANGE objects at the next lower level i.e. edit topics within that web, or add new topics to subwebs. ALLOWTOPICCHANGE kinda bucks the trend, but you can't read the way it works back up the hierarchy, unfortunately. There is no equivalent "ALLOWCURRENTWEBCHANGE" that restricts who can add topics to the current web; something which does my head in on a regular basis.

I'm not saying this is how it currently works; I am saying this is how it should work for as long as access controls are in-band.

-- CrawfordCurrie - 13 Mar 2007

@SvenDowideit: That's a good practice, to have a template web. I hadn't really considered it during planning; it is too bad we often don't have more time to deliver on TWikiApplications. (People often equate Wiki with "quick", I mean, it is in the name)

@CrawfordCurre: I agree what is really needed is a rethink of ACLs (both naming and scoping). The current methods are a bit clunky and sometimes counterintuitive. Each major activity should have associated with it one ACL verb no matter what scope rule is in effect. And the scope rule should be implicit. Such that if it is set on a web, then it applies to all non-overriding sub-webs and topics. It's silly that ALLOWWEBCHANGE and ALLOWTOPICCHANGE have different-sounding purposes yet they are the same, only that one of them is only valid in WebPreferences topics.

-- NeilRG - 13 Mar 2007

I do not find community acceptance on the original proposal. And the follow up discussions has not revealed any new proposals with a clear driver ready to implement it.

-- KennethLavrsen - 08 Apr 2007

I find this unfortunate. We have a clear proposal with code from a new contributor. I hope we have not lost Neil as a contributor because of this. This proposal is not needed by everyone, but it is a useful feature to hide the complexity of TWiki for non technical users.

-- PeterThoeny - 09 Apr 2007

Removed the text added in Committed Developer. If Neil want to drive it - let him add his name. Noone can add someone else's name just like this.

-- KennethLavrsen - 24 Apr 2007

8 month passed since Neil posted his feature proposal. We clearly lost a potential contributor here. I hope we will be more supportive in the future to new folks.

-- PeterThoeny - 03 Dec 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch Save.patch r1 manage 3.4 K 2007-03-08 - 23:11 UnknownUser patch to TWiki/UI/Save.pm
Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2007-12-03 - PeterThoeny
 
  • 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.