Feature Proposal: More Web Based TWiki Management

Motivation

Enable TWiki site administration with less IT overhead; allow division of labor between TWiki evangelists and IT support

Description

TWiki allows many actions to be administered from the web. However, more web based administraion is possible:

• UploadablePlugins

• Managing of templates, e.g. "oops" error messages

Anecdote

At the moment I find myself in a situation where IT has taken over administration of the wiki site, but where I am the wiki evangelist most responsible for adding features, making things work better for users, etc.

IT doesn't really adminsiter the wiki site at all. E.g. it is REALLY OLD - maybe >5 years old. It certainly has not been maintained much since I left to go to another company almost 3 years ago.

Why not just revert to me being the Wiki administrator? Manly because our IT department added one good feature, authentication using the universal Windows domain/idsid, so people don't need to maintain yet another password for the wiki site. But, because of various stupidities, such authentication means that the folks who have access to the CGI scripts must be sysadmins for security reasons.

So: I'm the guy who does most of the wiki stuff, but I need to work with an IT sysadmin for anything that cannot be done through the web interface. And, although the IT folk are great, they are always busy and cannot respond to all of my requests in a timely manner.

UploadablePlugins

I have already posted, in UploadablePlugins, about how I would like to be able to install plugins without IT support. Because of the aforementioned security concerns, this would require the plugins to be sandboxed.

Error Templates

Today I have encountered a new type of problem. As I put more stuff on the wiki, new users come aboard. They get error messages, like oopsaccessview.tmpl. They need more help.

I could point them to such help more quickly if I could edit the templates like oopsaccessview.tmpl. But at the moment that means that I have to submit a request to IT; experience seems to show a 3 day turnaround.

If I could edit the templates from the web interface, I could be able to make my users happy, quicker.

(In case you are interested, I have asked the IT sysadmin to just add "See TWikiLocalHelp" to all of the oops templates. This level of indirection means that I can manage it, as soon as IT responds.)

(This may be dated. If the templates can be modified from the current twiki, great, and sorry to bother you. Unfortunately, as noted above, the IT managed twiki is many years out-of-date. I have asked them to update. That is scheduled for several months from now.)

-- AndyGlew - 19 Jul 2005

Impact and Available Solutions

Note: Patch is attached as https://twiki.org/p/pub/Codev/MoreWebBasedTWikiManagement/twiki-foo-bar-patch.diff. The patch is against the TWikiAlphaRelease of 15 Feb 2004.

Documentation

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

Examples

Example uses of features introduced by proposal.

Implementation

Any comments on how the feature is implemented or could be improved

Discussion:

Andy, while this funtionality is desirable to the twiki admin - as you can call anything from a plugin, surly your IT staff won't really want you to upload executables (like plugins essentially are) without them being involved?

wrt templates, yes, i have always thought they should be reimplemented as topics in a TemplatesWeb (or something clever-er to seperate out different skins) - although we know from the CssTopic experiment done during the CairoRelease, that we can't afford to use live topics for everything.

-- SvenDowideit - 19 Jul 2005

Templates and CSS don't need to be "topics", just editable via web.

-- RafaelAlvarez - 20 Jul 2005

actually, i think it makes sense for anything we edit through the web to be a topic, but for certain types of topics, we don't use the render loop... for eg, a 'templateTopic' would be gotten for a view using the Store interface, but would not be processed like a topic is before it gets used as a template. similarly for cssTopics, and other types like that. the mistake we made during cairo was to treat the cssTopics with the full complexity as a final user topic (expanding TWikivariables and so on) which is quite unrealistic. if instead we implemented the TopicMimeTypes idea, and had a TWiki/Template type, it would be able oto be loaded faster. Similarly, the Text/CSS (or whatever) type would be saved as a .css file into the pub dir (to allow apache to run at full speed.

this TopicMimeTypes idea really needs to be implemented with the TopicObjectModel thing (Edin* ???)

-- SvenDowideit - 20 Jul 2005

This is what I meant by having PageTypes...

-- MartinCleaver - 20 Jul 2005

Templates can be kept in pub using the code patch in TemplatePathIsCounterintuitive

-- MartinCleaver - 08 Jul 2006