We relaunched the TWiki.org project with an expanded TWiki charter, and we invite you to participate! The TWiki.org Code of Conduct agreement took effect on 27 Oct 2008. We ask existing twiki.org users to opt-in. You need to opt-in to participate in the Blog, Codev, Plugins and TWiki webs. -- PeterThoeny - 27 Oct 2008
Tags:
create new tag
, view all tags

Question - need to be answered

Our company's intranet is using the December 2000 version. I'm just cautious about what path to take to update to the beta March version. I have yet to add more webs. So does the order matter? If I update first will I have any problems when I try to add additional webs. or would it be safer to just add the webs first then update? Also when is the stable version due out? Hello? Is anyone going to answer this for me?

Question - already answered

I work for a company who is looking to implement a wiki as a document management tool, primarily for helping developers write feature spec docs, and helping everybody else read and approve them. For all of that, it is not necessary for us to have any sort of access control. However, there are certain things (progress reports, evaluations, to-do lists, etc.) that would require ReadAccessPermission, and I am wondering about the state of it in the latest version of TWiki. Specifically:

Is there a way to specify, per page, the users who are allowed to see it? We don't know ahead of time who will necessarily want to be able to see a document, and it would be nice to be able to protect it at creation time. Most of the web will be publicly visible/editable, but a few things can't be, and those will only be shared among the people involved in whatever project/task is being discussed. It would seem very cumbersome to have to make a new web for every new project's protected documents, so that we could specify the exact list of people who can see it.

I saw the notes at ReadAccessPermission, which seem to indicate that the feature is already there, but that there are holes in it. We'll be running this on an authenticated intranet machine, so there is no access to the wiki with an authenticated username. Is this sufficient to get rid of the holes? Wandering around the code, the read-permission stuff looks to be there, so if the authentication is all that is needed, we are all set.

Also, what exactly does it mean to protect

Warning: Can't find topic ""."" ? I am a little confused about the comments in ReadAccessPermission about

Warning: Can't find topic ""."" - BruceDawson said he thought it was a non-issue, and then PeterThoeny said "Correct. Not done yet.". Does that mean that it is a non-issue, or that it will be a non-issue after some changes are made?

Finally, what exactly does it mean to protect search? Is this just because the first few lines are displayed in the search result? If so, it does not seem hard for us to add the code to also search the page for access permissions, and just not include the result if they are not met. I saw the comment about performance issues, but since the text is already being searched, and since we will be running on a fast machine, I am comfortable with it. Any thoughts?

  • TWiki version:TWiki20010315beta
  • Web server:Any
  • Server OS:Any

-- NathanArthur - 01 Jul 2001

Answer

For read access restriction I recomend to use the latest stable Beta, 15 Mar 2001. Read access restriction for individual topics is not documented in TWikiAccessControl but you can do that in the same way as imposing write access restriction for individual topics (use ALLOWTOPICVIEW instead of ALLOWTOPICCHANGE). It is not documented because there are some security issues:

  • Search does not check if the user is allowed to view a topic
  • You can use %INCLUDE% in a non protected topic to include a view protected topic.

So you can live with this limitation or change the code to plug those holes.

-- PeterThoeny - 07 Jul 2001

I just installed this beta version and copied users' pages and webs from my previously running December Twiki to it, and am now using the March version. Unfortunately, I cannot get view-protection to work. Perhaps I have done something stupid, but when I access any view protection at all, such as by setting ALLOWWEBVIEW to HendrikBoom? , it will not allow me to view anything in the web, even though it knows I am HendrikBoom? .

I do not have this problem with edit-protection.

Was there some residual bug in the March beta aboiut this? Or is it just likely that I did something wrong?

-- HendrikBoom - 09 Jul 2001

The March Beta works fine on many installations. Did you specify "Main."? As in: * Set ALLOWWEBVIEW = Main.HendrikBoom

-- PeterThoeny - 11 Jul 2001

Unfortunately, yes, I did. I even tried cutting and pasting it in from another permission that worked, just to be sure I had made no typos. So it probably is something I am doing wrong, and I'll have to debug this the hard way. I'd like to get it to make a debug-log entry every time it rejects a permission. And I'd like to do it in a stype that matches the rest of TWiki. What do I call to create a debug-log entry? And in what file do I find the log?

-- HendrikBoom - 12 Jul 2001

Type this: &TWiki::writeDebug( "any text" ); and look for the data/debug.txt file.

-- PeterThoeny - 11 Jul 2001

Answer to the outstanding question

Remember this is user mantained, so if the name "Spring 2001 release" is any indication, YMMV...

From my own experience, adding webs is relatively orthogonal to the changes in twiki, however, there are enough changes in the twiki core that might make you want to install at the very least the previous beta release (which is running happily at my site after some minor initial RCS problems).

Features that you will gain:

  • Most of the modern formatting is in place (with some small exceptions like tables and the like).
  • The new twiki program file structure is in place, which means less work when you configure the latest version
  • Many of the new twiki directives have been defined, like partial page inclusion and the like.
  • The plug-in structure is supported, even though this might change a bit for the stable release.
  • Table of contents and headings (using the ---+ formatting) is in place.
  • Most of the modern documentation is in place, thus requiring less changes afterwards.

Features that can be a stumbling block later on (unless you install the last beta):

  • New meta-data format, that means that any topic (including base pages for the new webs) created under the previous TWiki, will have some missing fields, that can cause some formatting problems in the near future.
  • Due to this meta-data change, customized search pages that relied on the old format will probably have to change.
  • The template format (specially plug-ins) seem to be somewhat in flux right now, while your current templates will very surely work, you might find yourself wanting to do a lot of changes to make them look nicer as per the most current releases.

For more information on what is involved check TWikiReleaseSpring2001UpgradeNotes.

In your position, I would probably just start a parallel twiki install with the latest beta, and give it a try. That way you can decide for yourself. (you might find that liberal use of a diff utility, specially for the documentation, is a godsend)

On actual release date, I would just monitor the last changes in the Codev web, specially the ones regarding bug reports in the current betas.

From my experience, what these guys call a beta might be much more stable than any Micro$oft release.

-- EdgarBrown - 17 Jul 2001

Yes. The stability of the betas is a sign of professional competence.

-- HendrikBoom - 18 Jul 2001

smile

-- AndreaSterbini - 15 Nov 2001

Topic revision: r15 - 15 Nov 2001 - 12:15:00 - AndreaSterbini
 
TWIKI.NET
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback