Feature Proposal: Topic preferences should always override user references

Motivation

TWiki provides an option for topic preferences to override user preferences. As a consequence, at every topic read, we need to read the user preference also, which might be a lot if there are many include files. Under mod_perl we would not even need to read the user topic again once we have a user loaded.

As I cannot imagine why you ever would want the user to override the topic preferences I propose to get rid of that useless, and time-wasting, option.

Also, this will allow us to read a topic once only, instead of once for access control and again for the real access.

Description

Always read preferences as follows:

• On script startup
  • Load system wide preferences
  • Load web preferences
  • Load user preferences
• On topic read
  • Load topic preferences

-- ThomasWeigert - 12 Jul 2005

Impact and Available Solutions

The current default is to have the user preferences override the topic preferences. This makes little sense and forces us to treat the Access control preferences differently (we would not want the user to be able to override the topic access control). However, if somebody relied on this bizarre "feature", that would not work any more.

Documentation

If necessary, user documentation of new features introduced by this proposal.

Examples

Example uses of features introduced by proposal.

Implementation

Implemented SVN 5999.

Discussion:

I'm not sure I understand the proposal. Let me see...

Currently, the default is that user preferences override topic preferences. The proposal is that topic preferences override user preferences, thus the order of preference loading would be:

• Load system wide preferences
• Load web preferences
• Load user preferences
• For each topic read (specified in the URL and INCLUDEd):
  • Load topic preferences

is that right?

-- RafaelAlvarez - 12 Jul 2005

And in addition, to get rid of the ability to allow user preference to override topic preferences.

Then, of course, we would make the system better based on this change...

-- ThomasWeigert - 12 Jul 2005

From the POV of user interface semantics, Thomas's proposal makes sense.

Its called "The Principle of Least Surprise".

If the user is looking at a topic and makes a change to the topic but nothing happens the user is suprised. As TWiki Gods we know its because the topic settings are being over-ridden. But the user doens't know that and calls support - which may not know either. Or perhaps he just gets frustrated and abandons TWiki and turns to something he can understand like MediaWiki.

-- AntonAylward - 13 Jul 2005

Agreed.

-- CrawfordCurrie - 13 Jul 2005

We could do with another couple of messages of support before doing this. Don't want to catch anybody by surprise....

-- CrawfordCurrie - 15 Jul 2005

Agreed.

-- MartinCleaver - 15 Jul 2005

so you're saying that if I have a Set GROUPID in each user's topic, that id's the organisational group they belong to, that you want someone to be able to over-ride it on the topic. I'm not quite convinced that this is quite correct either.

-- SvenDowideit - 16 Jul 2005

No, that is not what I am saying.... preferences come in many flavors:

• there are certain preferences that are final much earlier and cannot be overridden at all
• Then there are setting that are not even done in the normal way (such as what group a user belongs to).
• Then there are things that should never be set by a user (such as topic permissions or views associated with a topic)
• and then there are your ordinary preferences.

For the last, the order should always be site < web < user < topic (where "<" indicates the "weaker" preference). I have not yet seen an example, where a user preference should override a topic preference, but I have seen examples the other way round.

-- ThomasWeigert - 16 Jul 2005

On your example, the setting might be "I belong to Group X", i.e., Set GROUP = X . There is no way you could override that at a topic as this would just put that particular topic into that group. So you would have to construct an unusual way of doing settings just to make your example be a counter example. E.g., Set GROUP_X_MEMBER = TWikiGuest . But, honestely, if the setting is written this way, it seems hard to imagine why you wouldn't want to allow changing this somewhere else. Alternatively, you could always make it final at the user level.

-- ThomasWeigert - 16 Jul 2005

Thomas. Please get out of saying something without illustrating it. You do that in many places and its quite frustrating. We are not all as knowledgable about the internals and implications of design principles as you are. A few extra words would make it so much easier for the newbies as well as those among us who have focused on a different area.

Alternatively, you could always make it final at the user level.

-- AntonAylward - 16 Jul 2005

ah, yes. he nods wisely, understanding what Thomas is saying. In that case - I think you are right, its would simplify things, and work quite consistently. I'd forgotten ahout finalisation.

you know, maybe we should add a tickbox to the preferences table tto allow users to finalise a variable (ok, maybe, maybe not)

for Anton: i'd forgotten too: see TWikiPreferences - theres a FINALIZEPREFERENCES setting in which you list which variables are not able to be over-ridden by the next less secure level of preferences.

-- SvenDowideit - 17 Jul 2005

Implemented in SVN 5999. Note that this also solves PositionOfUserFormInMain.

Updated unit tests.

-- ThomasWeigert - 05 Aug 2005