create new tag
, view all tags
I like the Main.TWikiPreferences idea, but it seems that the current DEVELOP implementation (revision 5924, at the moment) of FINALPREFERENCES doesn't work very well with it. If the idea (correct me if I'm wrong) of Main.TWikiPreferences is that site-specific settings can be specified without touching TWiki.TWikiPreferences (thereby making upgrades easier), what's supposed to happen for the protected settings like WIKIWEBMASTER? It seems that Main.TWikiPreferences should be evaluated after TWiki.TWikiPreferences so that it can override whatever it wants, but that FINALPREFERENCES should be applied only at the web/topic/user level, and that Main.TWikiPreferences should be immune from its effects. Thoughts?

-- GregAbbas - 25 Jul 2005

I struggled with this as well. What you describe makes sense on the face of it. The reason I didn't do it that way is consistency. In all other preference topics, setting FINALPREFERENCES does exactly what it says on the tin; it says "these preferences are final". You are proposing changing that rule, making an exception; "these preferences are final unless you happen to be in TWiki.TWikiPreferences in which case they're not final until much later". So I chose what I saw as the lesser evil at the time, even though it could potentially lead to confusion.

I'm changing this to a DocRequest. It isn't a bug, it's a feature! hehe!

-- CrawfordCurrie - 27 Jul 2005

Consistency is overriding. It would be very confusing for the user were there such exceptions. There are inconsistencies in the preferences already we are trying to eliminate. So let's not add more....

-- ThomasWeigert - 27 Jul 2005

Hmm. Yeah I like consistency, but are you saying that settings on Main.TWikiPreferences should silently fail to override settings on TWiki.TWikiPreferences unless the user also remembers to add each one to the list of final preferences? The documentation for FINALPREFERENCES says "Site-level preferences that are not allowed to be overridden by WebPreferences and user preferences". It seems like the implementation should do exactly that, not "...WebPreferences, user preferences, and Main.TWikiPreferences ". But that's just my $0.02, this is democracy (supposedly) & I'm outvoted, but I've spoken and now I feel better. smile

-- GregAbbas - 28 Jul 2005

Yes, I'm saying that. As I said, it's the lesser of two evils. We need a documentation fix, for sure, but that's all.

If we had our heads screwed on right we'd be renaming Main.TWikiPreferences to Main.LocalSitePreferences and TWiki.TWikiPreferences to TWiki.DefaultSitePreferences. And while we're at it, TWiki.cfg to DefaultSite.cfg and setlib.cfg to DefaultLib.cfg. Now that would be consistent.

Anyway, consensus is to leave this as is, and document FINALPREFERENCES better.

-- CrawfordCurrie - 28 Jul 2005

I'll be glad to add some documentation if I can understand what exactly is the spec here. As I understand it:

  • If a preference setting exist in both Main.TWikiPreferences and TWiki.TWikiPreferences and is not included in the FINALPREFERENCE setting, then the setting is Main.TWikiPreference will override the one in TWiki.TWikiPreferences.
  • If a preference setting is included in the FINALPREFERENCE in either topic, then the version in that topic will take precedence.
  • If a preference setting is included in the FINALPREFERENCE in both topics, then...?
  • If a preference setting exist only in Main.TWikiPreference, then it will be included in preference settings. (BTW, this does not seem to work at present.)

Feel free to correct this. In a few days I'll add clarifying statements in Main.TWikiPreferences and TWiki.TWikiPreferences. Anywhere else?

-- LynnwoodBrown - 28 Jul 2005

Theoretically, the following should be the case:

  • The order of precedence is
    1. site (TWiki.TWikiPreferences)
    2. local site (Main.TWikiPreferences)
    3. web (web-specific WebPreferences)
    4. user (user hometopic)
    5. topic
where a higher number overrides a lower numbered preference.
  • If a preference setting is included in the FINALPREFERENCES it cannot any further be overridden by a higer preference

There are two issues that will need attention:

  • Currently the order of precedence between user and topic can be configured.
  • There are certain settings which should not be settable at the user level (access control settings, template settings)

-- ThomasWeigert - 29 Jul 2005

You are both correct. The legacy of FINALPREFERENCES just makes that order impractical, though.

The order of evaluation for an individual preference actually is:

What Condition TWiki.TWikiVariables On this site
local site   %LOCALSITEPREFS% TWikiPreferences  
default site   %TWIKIWEB%.!TWikiPreferences TWikiPreferences
web   %WEB%.!WebPreferences WebPreferences
topic %READTOPICPREFS% %WEB%.!FinalPreferences if %READTOPICPREFS% FinalPreferences if %READTOPICPREFS%

Rows are evaluated top down, subject to the conditions, with values for the preference set in lower rows overwriting those set in higher rows. If the preference name is in the %FINALPREFERENCES% in any row, evaluation stops at that row and no lower rows will be considered.

Unfortunately, if we changed the order of the top two, then final preferences set in the default site would override those in the local site. Since legacy twiki preferences topics contain final preferences overrides for just about everything, that would make local site preferences useless.

-- CrawfordCurrie - 29 Jul 2005

Thank you gentlemen - you have provided a much clearer picture of the current specs and the tradeoffs involved!

Regarding the relationship between Main.TWikiPreferences and TWiki.TWikiPreferences, the current spec presents an inherent dilemma for which I'm not sure there is a perfect solution.

To my mind, the ideal solution would be to have local site preferences override the default site preferences, period, and then have FINALPREFERENCES listed in either one apply to the lower levels. But perhaps that complicates the code too much...

Short of that, I would counter Crawfords arguement for why local site preferences should load before default site preferences. Assuming that most of the preferences listed in local site preferences are also in default site preferences, if local site preferences loads first, one would have to add every one of those preferences in FINALPREFERENCES for them not to be overridden by default site preferences. If local site preferences loads secondly, one would only have to be sure to delete any conflicting FINALPREFERENCES in the default site preferences - which I suspect would be a much shorter list. So I would vote for having local site preferences load second.

-- LynnwoodBrown - 29 Jul 2005

I understand, Lynnwood. It works the way it does because if someone uses an existing TWikiPreferences topic, it will have all those FINALPREFERENCES already in it. Yes, it complicates the code too much to change it. Please go ahead and document the way it works, I really don't want to change it again, especially if that requires a large content/upgrade change.

-- CrawfordCurrie - 30 Jul 2005

I really don't understand what is happening here. First, we discover that we can use Main.TWikiPreferences to use local preferences to override TWiki.TWikiPreferences. Then we have to create an abomination in the preference algorithm to account for that TWiki.TWikiPreferences has finalizations.

I think this is a really bad idea. I think we need to have a straightforward and logical preference resolution algorithm. If the price is some extra configuration or having to watch so that local preferences are not overridden, so be it. Configuration is done once in a blue moon, while preferences are used daily.

The easiest would be to take the finalizations out of TWiki.TWikiPreferences, but I assume you are hesitant to do so because of security concerns with the default installation?

-- ThomasWeigert - 02 Aug 2005

Yes, and because of legacy TWikiPreferences topics that already have FINALPREFERENCES. I'm not averse to doing it the way you describe, but I just didn't want to have to write the documentation. Which I could have done in the time spent discussing it in this topic frown

OK, my bottom line is: by all means change the order round BUT make sure it is properly and clearly documented in TWiki web and in DakarReleaseNotes, so no-one gets caught by surprise.

-- CrawfordCurrie - 02 Aug 2005

Crawford, my opionion is that we should strive for a clear and consistent algorithm. If we cannot do this, we should not document the current inconsistent algorithm so as not to make it a feature that cannot be removed later.

I think this is well worth the discussion time... smile

I am still not clear what the plan is... frown

-- ThomasWeigert - 02 Aug 2005

can't the FINALPREFERENCES be moved from TWiki.TWikiPreferences to Main, and then use the (logical) order thomas proposed ?

if so, UpgradeTWiki would need to be upgraded to deal with this change.

-- WillNorris - 02 Aug 2005

Let's take a step back and see what we are trying to accomplish...

I think the goal was to ensure that local site preferences are not overwritten when upgrading TWiki. (I hope that I did not miss some other goal.)

If so, why can we not use the configuration option to point $cfg{!SitePrefsTopicName} to the file with the local modifications?

I am still missing why we need to add the extra file that needs to be read many times during each topic visit....

-- ThomasWeigert - 02 Aug 2005

Crawford is off to the wilds of Scotland for a week so we won't be getting any more response from him for awhile. If we have some approach implemented and documented when he returns, I'm confident he'll be fine with it. I'm still prepared to do the docs.

Thomas, in your last post are you suggesting $cfg{!SitePrefsTopicName} could be configured to point to an alternative preference topic and then TWiki.TWikiPreferences would be ignored all together? The only reservation I have with this approach is that it's nice to put only the few preferences I need to override in the local site preferences and let TWikiPreference take care of the rest and pick up any new preferences that might be added during upgrades.

I still support your proposal of simply loading Main.TWikiPreferences second so that, by default, it overrides TWiki.TWikiPreferences. Managing the few "legacy" FINALPREFERENCES in TWiki.TWikiPreferences that might conflict seems like the least-troublesome solution.

So, Thomas, if you'd like to change the code, I'll provide the docs. Otherwise, I'll proceed with documenting Crawford's approach (probably tommorow).

-- LynnwoodBrown - 02 Aug 2005

OK. I am on a looong flight back to Chicago from Bangalore. So I might get to this...

-- ThomasWeigert - 03 Aug 2005

Thanks for those intercontinental flights! wink

-- FranzJosefSilli - 03 Aug 2005

Implemented in SVN 5997. Supplied additional unit tests.

The order of preference precedence is now as follows:

What Condition TWiki.TWikiVariables On this site
default site   %TWIKIWEB%.!TWikiPreferences TWikiPreferences
local site   %LOCALSITEPREFS% TWikiPreferences  
web   %WEB%.!WebPreferences WebPreferences
topic %READTOPICPREFS% %WEB%.!FinalPreferences if %READTOPICPREFS% FinalPreferences if %READTOPICPREFS%

FINALPREFERENCES at any level cannot be further overridden. To facilitate using %LOCALSITEPREFS% I have moved all finalizations from TWiki.TWikiPreferences to Main.TWikiPreferences.

Main.TWikiPreferences would hold the local customizations and should not be changed by the default build. There still is the risk that Main.TWikiPreferences needs to be changed in the future if new finalizations have to be added for some preferences. However, that will most likely happen much less than TWiki.TWikiPreferences is being changed.

Note that we strictly speaking do not need the finalizations and could rely on the user providing appropriate finalizations.

Lynnwood ready for your documentation.

-- ThomasWeigert - 04 Aug 2005

Thanks Thomas! After all is said and done, there's not a lot of documentation to add. I see you've already made some changes to the notes in TWiki.TWikiPreferences. The only other locations that I can see adding some mention of this are:

The chart above is useful. Where could we put it?

It occurs to me while thinking about his is that it would useful to have a TWikiSecurity topic that touches upon all facets of security on a TWiki site—this being one small piece of that.

-- LynnwoodBrown - 05 Aug 2005

I think that in TWiki.TWikiPreferences (near the top) there should be some explanation of what preferences are, how they are set (don't forget to add an explanation of setting preferences through meta data using the "more..." screen), where they can be set, and their order of precedence... There also needs to be a better explanation of finalization. And an explanation of what the "Edit" button does. I suggest that you replace the first paragraph (after the block quote) including the bulletted note.

-- ThomasWeigert - 05 Aug 2005

After the change due to TopicAlwaysOverrideUserPref the order of preference precedence is as follows:

What TWiki.TWikiVariables On this site
default site TWiki06x00.TWikiPreferences TWikiPreferences
local site Main.TWikiPreferences TWikiPreferences  
web Codev.WebPreferences WebPreferences
user Main.TWikiGuest TWikiGuest
topic Codev.FinalPreferences FinalPreferences

-- ThomasWeigert - 05 Aug 2005

Good suggestion. That's the direction I'll pursue.

-- LynnwoodBrown - 05 Aug 2005

Committed documentation with SVN 6005 and 6006. These changes were to Main.TWikiPreferences & TWiki.Preferences. Will continue to look as other doc changes/additions needed.

-- LynnwoodBrown - 05 Aug 2005

Added documentation to TWiki.TWikiInstallationGuide with SVN 6007. Looked over TWikiUpgradeGuide but realized that we need an entire guide for upgrading to DakarRelease - so I added a new bug item for this with intent to start working on it.

-- LynnwoodBrown - 05 Aug 2005

they're in DakarReleaseNotes

-- WillNorris - 06 Aug 2005

Fixed missing newline disabling PreferencesPlugin on TWiki.TWikiPreferences. Made some minor corrections.

Lynnwood, the table on TWikiVariables#Preferences_Variables needs to be updated also (mention topic level preference, add into all rows of the table where appropriate). I also believe that the table is not always correct, e.g., when it says that a setting is only good for "S, U", I think it works on the web level also, but that should be verified, and the table should be updated, if incorrect.

-- ThomasWeigert - 06 Aug 2005

Thomas - thanks for pointing to the additional doc needs. I will follow up on that although it may take a while to test out all the Preference Variables and I'm heading into a particularly busy week. But I'll keep at it. Looks like a good candidate for a test case.

-- LynnwoodBrown - 08 Aug 2005

Lynnwood, I don't think you need to test out every single one. I think we should just pick one or two to verify that in fact the limitations shown are correct. If not, we can just eliminate the column to be on the safe side.

-- ThomasWeigert - 08 Aug 2005

Documentation updates are tracked in Bugs web. Marking this as done.

-- CrawfordCurrie - 28 Aug 2005

Edit | Attach | Watch | Print version | History: r30 < r29 < r28 < r27 < r26 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r30 - 2006-02-15 - LynnwoodBrown
  • 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.