create new tag
, view all tags

Feature Proposal: Save Topics by Admin User


In the "Use TWiki as Web Application Platform" mode of TWiki, I often have a need of disallowing users to edit a topic, but wanting users to be allowed to edit portions of the topic. Example: A topic contains some table that I want to allow users to update (using EditRowPlugin or similar) but I do not want them to edit the rest. Or I want to allow users to add comments to a topic, but not edit the rest of the topic.

I am using this for my class. I have for example a homework description. I allow students to ask questions or comment on the homework, but I do not allow them to change the homework itself.

Description and Documentation

Allow to specify that under certain cirumstances one can obtain a lease on a topic without being allowed to edit the topic.

For example, in SignaturePlugin, allow the designated user to sign the topic, even when the user is not allowed to edit the topic.

I have currently implemented this by modifying TWiki::Func::checkAccessPermission such that it looks in a config variable whether in the current context we should allow any user to modify the topic, independent of the access protection.


See above.


WhatDoesItAffect: Usability


-- Contributors: ThomasWeigert - 2010-09-11


Certainly a viable solution. I am a bit concerned on the complexity it introduces, as well as exposure to potential security holes. I usually solve above mentioned problem with composed topics, e.g. INLCUDEs. For example, you can include a comment section or push comments to an included page as done in the Blog application in the Blog web.

-- PeterThoeny - 2010-09-11

Correct for some of these applications. For example, I can deal with comments as you say. However, if you want an editable table, at a minimum, the topic with the whole table must be editable. So even if you do all kinds of tricks such as hiding the edit link (I have a "noedit" skin, but that is another sob story), an experienced user can change the whole table, such as deleting it. More serious with the SignaturePlugin: There we want exactly one data item in the topic editable by a specific user, but nothing else on the topic. I will explore some more with your idea, but at a minimum, it will create a lot of overhead due to the creation of many small topics that just have the editable items.

Maybe there are other good ideas out there.

I just propose the use case, my current implementation is not the proposed solution. One could, of course, also deal with each of the solutions as a custom scenario (e.g., extend the SignaturePlugin to support this, as it does have an extra layer of security checking already).

-- ThomasWeigert - 2010-09-11

Because of version control and peer pressure I am not so much concerned about being able to bypass the intended workflow. Once can always verify who made a change, intentional or not.

As for read-only skin, this is worth formalizing with a separate proposal. I have had needs in the past where based on user, the current page should be editable or not.

As for securely changing certain parts of a topic, for inspiration see proposed spec at EncryptPluginDev.

-- PeterThoeny - 2010-09-14

Later.... on read-only skin, I see now that you propose that at CreateNoEditSkin.

  • These are unrelated proposals. I see them as orthogonal. -- ThomasWeigert - 2010-09-15
-- PeterThoeny - 2010-09-14

I checked some more. The trick with putting the comment in another topic and including it only works partially. After submitting the comment, the user is left at the other topic, not at the original topic they were looking at. This requires another navigation and reload to get back to where they left off. Not a good user experience.

  • Actually that is possible with the redirectto parameter, as done by the Blog application on twiki.org. See docs as TWikiScripts and CommentPlugin. -- PeterThoeny - 2010-09-15
    • Fair enough, but that works only for when the edit script was invoked, and some plugins can easily add that mechanism. But what about the existing plugins. E.g., EditTablePlugin or EditRowPlugin, which is a typical application in the mode I am envisioning? -- ThomasWeigert - 2010-09-16
  • The redirectto parameter works as well for the save script. Good point on EditTablePlugin and EditRowPlugin, they would need to be enhanced. -- PeterThoeny - 2010-09-16
Please see continuation below...

-- ThomasWeigert - 2010-09-15

I thought about this some more.

I believe there are four permission modes on a topic:

  1. Not allowed to view (or edit)
  2. View only
  3. Edit only with (designated) controls
  4. Full edit of topic
So if a topic has, say a comment submit and a signature for signing, permission 3 would allow the user to submit comments or sign the topic, but not to go into edit mode and make wholesale changes to the topic. Permission 4 would allow the latter.

My earlier suggestion (and internal hack) is just a poor-man's version of this 4 level permission scheme.

-- ThomasWeigert - 2010-09-15

Using the redirect strategy (discussed above) seems to imply the following: By default the scripts should be changed to redirect after any activity to BASETOPIC rather than TOPIC. This might be intended in general.

However, I think the redirect strategy is not advisable. The result is that such topics are always broken into multiple topics, with some of the subtopics potentially in different webs. Not only does this lead to a confusing proliferation of topics, but it might remove essential items from the topic itself. For example, a signature table is now moved to a separate topic, so that users can sign without being able to edit the body of the text they sign. Now we have lost the connection between what the user signed and the signature. The signature topic could now be included by any other topic, potentially having a user sign something that is the opposite of what they intended. The same argument can go with comments or text in tables. Once you divorce the text from what the comment is on, the comment could be used for all kind of nefarious purposes.

I believe that the best strategy to a complex TWiki topic with multiple levels of permissions is to provide the additional level of permission I discussed above.

-- ThomasWeigert - 2010-09-16

I added the redirect attribute to EditRowPlugin, to test Peter's approach. While it does work as advertised, i.e., we could assemble a topic from many different includes, I believe the point I made above is definitely correct, and in my opinion, decisive. We loosing the connection between the topic and the contents. Includes should be used for when topic is assembled from independent pieces, not when it is assembled from dependent pieces.

-- ThomasWeigert - 2010-09-19

See see the need based on your reasoning on 2010-09-16.

Here is an idea: I think KISS is a good approach for one topic equal one ACL setting. Now, plugins can circumvent security, e.g. it is up to the plugin author to adhere to the security policy. In your signature example, how about locking down the topic to one group, and restrict the signature action to another group? The signature data can be stored in meta data that only the plugin is supposed to modify.

-- PeterThoeny - 2010-09-20

Yes, that would be one way to go. It is just a little strange if a plugin were to violate the basic protection of the page. But there is nothing technically in the way here. I am already checking in SignaturePlugin whether a user is allowed to sign, independent of the topic permissions. At this point I am more strict than the topic permissions, but there is nothing that would stop the plugin from being less strict.

Probably there should be a configuration flag that a plugin should check whether it should obey the topic permissions or whether it can override them.

You know, it is funny. I never thought of the plugin not obeying the topic access permissions. But there is nothing in the code that would stop a plugin to do so.

-- ThomasWeigert - 2010-09-20

The one thing I don't like about this approach is that whereas before we had access control concentrated in the web preferences, now it becomes spread to the plugin invocation. But I guess that can be set at the web level also as a plugin preference.

I think what I will do is to add a Contrib which provides a second version of checkAccessPermission that implements this second level of access control, mirroring what we already do.

A plugin can then decide to leverage this layer or not.

-- ThomasWeigert - 2010-09-20

Looks like a sensible approach.

-- PeterThoeny - 2010-09-20

OK. I almost got it done but then I got stuck. Here is the problem.

It is relatively easy to get a layer in addition to the current protection working as an overlay to TWiki::Func::checkAccessPermission. However, I ran into a gotcha. When finally saving the topic, one typically calls TWiki::Func::saveTopic, which in turn calls TWiki::Store::saveTopic. For inexplicable reasons, this function checks once again for access protection. This seems strange, as the usual paradigm is to check for access permission, lock the topic, save the topic, and then unlock the topic. I think this extra check for access permission is unneeded and just slows the save process down. Note that for saveTopicText we provide a choice of whether we want to check for permissions or not. The same should be available for saveText.

-- ThomasWeigert - 2010-09-22

Studying this I also ran into the following question regarding TWiki::Store::saveTopic:

It does not check for access permissions, when no user is given. However, if the user is undefined, the RCS backend complains.

I think what really is wanted here is an option that allows us to decide whether to check permissions or not, similar to TWiki::Func::saveTopicText.

-- ThomasWeigert - 2010-09-22

Agreed. I think we need to enhance TWiki::Func::saveTopicText accordingly, with compatibility in mind (new parameter should be fine.) Best to create a new change proposal for that.

-- PeterThoeny - 2010-09-22

Thomas posted proposal to fix save topic at TWikiStoreSaveTopicWithIgnorePermissions.

-- PeterThoeny - 2010-09-22

Back to the topic at hand... I will create a plugin that overrides TWiki::Func::checkAccessPermission to provide this functionality which then can be turned on or off by a config.

I wanted to do this as an addin but found that addins cannot override the core code (probably due to some loading order), but I did not dig into why. If you happen to know, please advise. II have it working as a plugin.

-- ThomasWeigert - 2010-09-23

Not sure why. Plugin is cleaner anyway (less likely to break on upgrade).

-- PeterThoeny - 2010-09-23

I am embarrassed to confess, I cannot quite see where the Contrib are loaded. In the past, we had the distinction that Contrib packages were some kind of foundation that might not have to go through the Func API. But it appears that you are not making such distinction?

-- ThomasWeigert - 2010-09-23

Contribs are more tightly integrated with core code, thus break more easily on upgrade. All contribs live below the TWiki::Contrib name space.

Somewhat confusingly, some TWiki applications are packaged as contribs instead of add-ons. TWiki apps typically only ship with twiki/data and twiki/pub files.

-- PeterThoeny - 2010-09-23

Yes, I understood that. I was scanning the code and could not locate the point where the contribs are actually loaded into the running code. I am expecting some function that looks through lib/TWiki/Contrib and loads these modules one by one. But so far I have not located such piece of functionality...

-- ThomasWeigert - 2010-09-23

OIC. There is no standard way to discover and load contribs, as is the case with plugins. This is up to the task. For example, the LdapContrib implements a password handler (activated via configure).

-- PeterThoeny - 2010-09-23

OK, thanks. Now I understand why my contrib did not load....

-- ThomasWeigert - 2010-09-24

Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2010-09-24 - ThomasWeigert
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.