create new tag
, view all tags

Bug: Inconsistent Handling of Preferences

As everybody knows, we have a multi-level hierarchy of preferences:

  • Site-wide
  • Web
  • Topic
  • User
While the hierarchy is clear from Site to web and below, it is not always clear how user and topic are related. There is a preference setting which says whether one should pay attention to topic settings (READTOPICPREFS) and one that tells whether topic or user are more important (TOPICOVERRIDESUSER).

However, independently of all these settings, the web permission algorithms are independent of these settings, albeit these are defined to be preferences.

For example, if the preference resolution algorithm were to be used for ALLOWTOPICCHANGE with default settings, then every user could allow him or herself to edit every topic. Luckily, the access checking algorithm ignores the preference algorithm and uses its own scheme.

However, that is not without problem either:

The access control algorithm begins by looking for 3 spaces followed by '*' followed by Set and equal sign. But what if we had chosen to store these settings in meta data preferences so that they don't mess up the topic text? Then the special algorithm would not apply and the preference resolution from above would kick in!

Here are two points:

  • Topic preferences should always override the user settings as the topic was carefully designed to use those settings, e.g., the user should not be able to override the security settings for a topic. But similarly, if a topic sets some other flag, the user should respect that flag also.
  • Further, the resolution algorithms for preferences and access control should work the same way (as access control settings are just preference settings).
  • Finally, preferences should work whether using the explicit Set notation or whether using metadata to store the preferences.
Alternatively, there should be certain settings which are never treated as user-level settings, such as access control settings or template settings.

Test case


TWiki version: TWikiRelease02Sep2004, DakarRelease
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  

-- ThomasWeigert - 12 Jul 2005

Impact and Available Solutions

Follow up

Fix record


IMO preferences are data about the page and as such belong in that the meta data.

-- MartinCleaver - 12 Jul 2005

I agree, and this is supported in DakarRelease as an alternative. But in this topic I'd like to focus on the consistency issue...

-- ThomasWeigert - 12 Jul 2005

My ha'porth

  • Topic preferences should always override the user settings...
    • yes, absolutely. Scoping rules should be consistent.
  • Further, the resolution algorithms for preferences and access control should work the same way (as access control settings are just preference settings).
    • ah. Access controls are preference settings just because whoever built them was lazy. The preference syntax was used, because it was too hard to do preferences any other way. I don't favour compounding that error.
  • Finally, preferences should work whether using the explicit Set notation or whether using metadata to store the preferences.
    • I favour dropping (or making optional, default off) the Set syntax for preference settings.

I really don't favour keeping access control permissions interleaved with text in topics (a.k.a preference settings). It's hard to write decent tools that abstract access control administration without tripping over other mechanisms. There is a clear and present danger of conflict with other mechanisms, such as user preferences and FINALPREFERENCES that can never be resolved.

There are patterns for perfectly good permission mechanisms, well proven in use. Access control lists are extremely flexible, consistent and easy to implement and understand (take it from me; I had a hellish time making the existing TWiki scheme even half-way sensible). Concepts such as permission inheritance from parent topics, consistent web and topic access controls, controls on other resources such as plugins or attachments, are all much easier to do.

This has riled me enough that I just started AccessControlLists.

Oh, BTW, for the purpose of Dakar I favour Thomas' proposal. We have already changed the semantics of the permissions; a further simplifying change is a good idea.

-- CrawfordCurrie - 13 Jul 2005

Implemented this proposal. Updated the unit test. In SVN 6011.

Access control is now done by checking the relevant preferences, rather than scanning the source text for the settings. Not only does this give us the same mechanism for ordinary preferences and access control, but it also applies this consistently everywhere (in Cairo, for example, access control was not checked if the settings where put into a form, us it was supported by UsingFormsForSettings). Any future improvement can be applied to both situations.

I had also expected some small improvement in performance, as on an ordinary topic view one read and scan of the topic is avoided. However, the difference did not show up as significant in profiling or timing.

Thus, the benefit is primarily one of consistency (and fixing the defect of not allowing access control settings in metadata). We can now, if desired, build a preference setting system (including access control) based on an editor for metadata. (Note that the current metadata based editor for settings still uses the * Set =... syntax.)

-- ThomasWeigert - 06 Aug 2005


Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2006-04-06 - MeredithLesly
  • 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.