Tags:
create new tag
, view all tags

Question

Is there anyway to have the initial access settings for a new topic be inherited from the parent topic? Or do I need to use multiple (perhaps nested) to do something like this?

I am setting up a TWiki based wiki for some of my users, although I am not very familiar with TWiki or wikis in general. I have successfully installed TWiki 4.1.2 with Apache authentication, and have added several plugins (WebPermissionsPlugin, WysiwygPlugin).

I am somewhat confused at how to design the overall wiki. Because the documentation recommends not creating too many webs and instead leverage the power already present in topics, I have been trying to have all user pages in a single web. Because as the different groups in my dept will have differing requirements when they start using the wiki, I wanted a design which is reasonably flexible. I was hoping to create homepage topics for each group, and members of the group can then create children of this topic inheriting the same basic access rights (e.g. change, and maybe even viewing limitted to members of the group)

I have tried a number of tests, but whenever an user creates a topic it seems to grant view and change access to everyone, regardless of what the access on the parent topic is. Am I doing something wrong, or is this a feature not available in topics and I should probably define separate webs for each group?

Thanks in advance for your advise and suggestions, and for this fine product.

Environment

TWiki version: 4.1.2
TWiki plugins: standard (come with 4.1.2) plus Wysiwyg, WebPermissionsPlugin
Server OS: Linux
Web server: Apache 1.3.x
Perl version: 5.8.x
Client OS:  
Web Browser:  
Categories:  

-- TomPayerle - 27 Mar 2007

Answer

ALERT! If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

Many initial wiki deployments tend to lock down a lot of content. Once the teams get used to work in a wiki, access control is no longer used to lock out users for write, just for read. And just for large content areas, such as locking down all project related engineering content to be viewed only by Engineering and Marketing. And this is typically done on a web level. Please read TWikiAccessControl#ImportantConsideration.

If you want to lock down individual topics you can do that. Keep in mind that this is time-consuming and error-prone.

If you want to do that on a team level you could create a form in each team homepage to create new topics based on a template (similar to the MeetingMinutes app). In the template topic you could define the access control settings for the team.

-- PeterThoeny - 27 Mar 2007

 
Change status to:

Thanks for the feedback. I am aware of the warning against too much locking down of content, and am trying to overcome my impulse as sysadmin to do so. This question stemmed more from the fact that in an academic department which is unfamiliar with wikis, as users get interested they may wish, rightly or wrongly, to lock down content at least initially. And I am trying to plan past the initial group requesting the wiki (I can stall a little on installing a new service, but users do not always understand how a trivial change to an existing service that did not plan for such can be far from trivial frown )

I will need to read up some more on templates; what little I've done with them has been related to skins and appearance, and apparently they have some other uses as well.

But looks like it would be best to use webs for the major research groups, and if they need some something special on particular project will look into the template approach. (Manual setting of permissions on individual topics is out of the question.)

Topic revision: r3 - 2007-03-27 - TomPayerle
 
Twitter Delicious Facebook Digg Google Bookmarks E-mail LinkedIn Reddit StumbleUpon    
  • Download TWiki
TWiki logo Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2012 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.