Feature Proposal: An enhanced EditPreferencesPlugin which stores values in Main.TWikiPreferences

Motivation

This proposal is for GeorgetownRelease!!

Avoid having people edit settings in TWiki web for both TWikiPreferences and plugins

Description and Documentation

We used to have the %EDITPREFERENCES{"TWikiPreferencesForm"}% in the TWikiPreferences. And we removed it because it was an invitation to edit the TWiki web one.

We have also changed the preferences order so that Main.TWikiPreferences override Plugin settings. So we have taken the right steps to make upgrading the entire TWiki web possible as long as people store all settings in Main web. But this is not so easy and not so obvious.

You have to copy the setting from either TWiki.TWikiPreferences or a Plugin topic to Main.TWikPreferences. And for plugins you even have to prefix the setting with the plugin name.

In order to ease this I suggest that we revive the EditPreferencesPlugin so it does the work for you.

In both plugins and TWiki.TWikiPreferences the plugin will show the edit button. And when you click it you can edit the settings (including enabling and disabling the setting). But the actual value is stored in Main.TWikiPreferences. For plugins with the right prefix.

When you then view the TWiki.TWikiPreferences you see the altered setting from TWikiPreferences in a different colour.

When you edit a little button can be clicked which reverts to the default value (the actual value stored in TWiki.TWikiPreferences or plugin topic).

Impact

• Easier upgrade
• Easier and safer editing of prefs
• Either needs adding plugin to all plugins (default plugins to start with) OR make it per default work on all settings on all plugin topics of activated plugin.

Implementation

I am not sure when I get the time to work on this which for me is a large task and maybe more difficult than I first thought.

To get it out of the 14-day rule queue I declare it accepted by 14 day rule and park the proposal for now.

-- Contributors: KennethLavrsen - 02 Jun 2007

Discussion

How about rethinking configuration management a bit further, instead of creating yet another plugin that sets out to cure a problem that, frankly speaking, goes much deeper.

Editing WebPreferences or TWikiPreferences, either using plain edit, or a GUI facelift like EditPreferencesPlugin, seems to be falling behind what competing tools are doing wrt configuration management.

Right now, we have two completely separated worlds of storing configuration settings: one is topic-based, the other is perl-based, accessed using configure. The latter does have a GUI but is limited in the way you can expand it and only thought to be used by admins, that is no role-based administration. Comparing topic-based and perl-based configuration management as we have it right now could be elaborated more thoroughly but I skip that for now.

IMHO, we need a new admin'ing approach to TWiki.

The following things need to be brought together into a single admin console:

1. site-level configuration
2. web-level configuration
3. plugin configuration
4. account management (including bulk registration etc)
5. access management (in the vein of WebPreferencesPlugin)

What else do we have on a daily TWiki admin show? These things are uniformly distributed all over the place where it should be a one-stop place.

In the long rung, we should abandon topic-based configuration management as far as possible because that's (a) unusable and (b) a resource hog. WebPreferences of all webs are parsed in on every click, most of which never change again, once installation finished. It had its legimitation once upon a time. But that needs a change as it grows up.

Don't understand me wrong. If you want to create a new preferences plugin, just go for it. But I'd opt for a more radical change for georgetown. Georgetown is a dot-o release, which means an anything-can-change-release. That's a chance to strive for a bit more.

-- MichaelDaum - 27 Dec 2007

I have had similar thoughts.

One thing though. Today configure is protected by ONE password and in general it is a bad idea when multiple people use same password. It is not such a bad problem now because the configure settings is not something I see a team of TWiki admins maintaining. In our TWiki installation I am the only one with access to configure. But we are around 5-6 people in the TWikiAdminGroup who can change the settings in various setting topics and edit any topic.

Whatever we come up with of better ideas for Georgetown I find it important that I can still seperate the people that can define directories, install plugins etc from the normal admins.

The advantage of the topic defined settings is that it is simple. Simple to create your own settings. Simple to document.

We have to watch out that we do not create something very efficient that requires too high skills to use for the users.

With an improved storage model where all settings and ACLs are stored not only in flatfiles it should be possible to keep simplicity and get much better performance.

But just making a plugin that tries to mend the problem of having settings multiple places is not really such a good idea which is also a reason why I parked the proposal.

-- KennethLavrsen - 28 Dec 2007

Okay, let's see if we can come up with a role-based unified configuration management.

-- MichaelDaum - 28 Dec 2007

sounds like the work that has been going on to abstract Meta, and then use TOM like addressing to get and set values is exactly what you are asking for (and then a UI wrapped around that)

-- SvenDowideit - 29 Dec 2007

Good discussions here. For complete audit trail and for KISS I suggest to keep storing ACLs alongside topics (ACLs are automatically version controlled) and to cache ACLs in a way to retrieve it fast.

-- PeterThoeny - 02 Jan 2008