Now that there's this nifty way of setting topic preferences via Edit settings (via manage.pm), there needs to be a way to prevent people from changing them even if they're allowed to edit the topic. For example, one might set VIEW_TEMPLATE and not want users to be able to change that. (At least not easily; power users can do a lot more than would make a TWiki app writer comfortable.)

So, I guess it would be ALLOWTOPICSETTINGS and DENYTOPICSETTINGS?

(And which is it, settings or preferences?)

ML

---

If this gets implemented then there will be two different settings to control the access rights to a topic. It gets so complicated to keep track of that both the admin, the web masters and the users will have a hard time working out what to setup.

I say - if a user is smart enough to find his way into the settings page and he has the rights to change the topic - he probably also has a pretty good reason to change the settings when he does it.

We have to be careful we do not make TWiki too complicated to use or optimize it towards a few very special applications that TWiki was not really intended for. And we have to take care that TWiki remains a Wiki! And not just another CMS.

Last - access rights is one of the features that has a large part to play on performance. Adding yet another access right feature is going to be yet another step in making TWiki slower.

KJL

if a user is smart enough to find his way into the settings page

That's a pretty sad commentary on the UI.

But more to the point, certain topic "settings" are more the purview of an admin or developer than otheres. That is, editing the contents of a topic is very different that editing settings such as VIEW_TEMPLATE, EDIT_TEMPLATE, and such, which clearly (IMO) don't belong in the whiteboard.

For example, when I suggested that form-based applications should use %META{"form"}% in their contents rather than removing the twisty for the form, the response was "it's too easy to delete it by accident". The right solution to stuff that shouldn't be deleted is a custom VIEW_TEMPLATE. In this case, the form would not be part of the editable portion of the topic but would be displayed there.

ML

---

I long ago pointed out that using "settings" for access control was a chronic kludge and that access control should not be in-band.

What you are pointing out, Meredith, is that these controls are in-band and they shouldn't be. Once we differentiate access control from other settings things become a lot easier.

For a professional tool in a corporate setting, access control is needed. Sorry, things like Sarbanes-Oxley and many other regulations demand that.

Control over access control and TEMPLATE issues is orthogonal from control over the data content. Think of the analogy with a file system. The commands like chmod and chown don't affect content. I can grant permission to edit a file without granting permission to change its access permissions.

Can this be implemented in a light-weight fashion? I believe so. Moving access control out of band means we can use thigns like hash databases. We can have the default fall back to a web level.

Will it make the UI more complicated? Yes and no. No, it won't make it more complicated for those that don't need to manipulate these thigns. In fact it will clear out the current in-band stuff that confuses many users.

Yes there will need to be a GUI for those that do have authority and need - Meeedith's "admins and developers". But so what? I have this in my UNIX and MAC interfaces - I have to drag up a GUI to do a chmod or chown/chgroup or any of a number of other 'attributes' that are out of band to the file contents. So what? Such people are expected to be knowledgeable out such matters.

Moving access control out of band will allow significant performance imnprovements. Access control over access cotnrol is a corporate necessity.

-- AJA

Access control over access control, and taking access control out of band, are not necessarily the same thing. Access controls can be protected even when they are in band - it just depends on how much you are prepared to compromise the topic text during a save operation.

Sorry, this isn't Urgent, and is not appropriate for a minor release.

CC

Perhaps I wasn't clear. I wasn't talking about settings in topic text, only settings done through the "edit settings" mechanism, which puts them into META:PREFERENCES. So I'm not talking about ACL over ACL but, rather, ACL over non-text content.

And it's not just corporations that need ACL. My first major TWiki app is for a school, where ACL is very important to keep things away from the prying eyes and fingers of the children.

ML