Item14430: Since Item14048, cannot transition a topic unless user has edit access

Changes made under Item14048 modified the plugin so that the AllowEdit of a destination state is automatically inserted into the ALLOWTOPICCHANGE of the transitioned topic. However, that now means that a user has to have CHANGE access to any topic that they want to transition, as edit access is required. This worked previously because users generally had CHANGE access at a web level, but the Item14048 change now enforces permissions at a topic level and effectively removes that right.

The ability to transition, and the ability to CHANGE, are different things, and should not be conflated. The plugin needs to be able to ignore CHANGE access limitations on topics where the transitioning user is permitted to perform the transition under the rules of the WorkflowPlugin. This needs to be clearly documented, as it means there will be no global mechanism for blocking transitions any more (previously you could simply remove CHANGE access at the web level, and this would block all transitions in the web).

-- CrawfordCurrie - 08 Jul 2017

When would you prefer to have a setting where somebody is allowed to transition a topic but not have change rights? Could you describe a real-life scenario where that would make any sense?

-- MichaelDaum - 08 Jul 2017

Being able to transition a topic when not being able to edit is how my company has been using this plugin for quite a few years. In general, this mechanism is used when the topic is pushed to a state for others to review (say FORREVIEW where they lose access to edit it), but then they discover an error and want to transition it back into a state where it can be edited again (say UNDERREVISION). Also, if only the users that are allowed to edit the topic are allowed to transition it, how does the Allowed column of the transition table work? Is it supposed to further restrict users that can transition, or allow additional users?

-- DeanSpicer - 09 Jul 2017

Foswiki unfortunately conflates CHANGE and EDIT, where in fact they are different things (EDIT necessarily implies CHANGE, but CHANGE may not imply EDIT).

• For example, I may have a group of reviewers who can review a document, but they are not allowed to edit. The only actions available to them are transitions PASS or FAIL. So they need to be able to CHANGE (transition) the document, but not EDIT (modify the content with an editor).

However we're stuck with CHANGE meaning EDIT for historical reasons, and I'm not proposing changing the core semantics at this point.

Normally this can be solved by simply ignoring the permissions during the $meta->save in the plugin - this is how the CommentPlugin works, where ALLOWCOMMENT implies ALLOWCHANGE, works. It's the plugin's responsibility to check your right to transition. This can be done in the WorkflowPlugin by simply adding ignorepermissions to the transition save (though permissions will need to be checked more rigorously in the REST handler). However it will only work for simple transitions. Any transition where the form changes, goes through an intermediate edit step, and it's not clear to me how to pass TRANSITION rights through this step.

-- Main.CrawfordCurrie - 09 Jul 2017 - 08:47

Well unfortunately, after a quick survey of the different workflows used at my workplace, many of them involve a form change. Having this functionality work as before is a big deal for me. It could actually block us from upgrading WorkflowPlugin past verion 1.14 (March 2015).

Also, it would appear from reading Item14048 that there are a couple features that are currently coded and aren't described in the documentation (allow view column, transition comments). Even the example state table and transition table are now inconsistent with how the WorkflowPlugin currently behaves.

-- DeanSpicer - 10 Jul 2017

CDot, I see you point. It means we will have to distinguish ALLOWTOPICCHANGE from ALLOWTOPICTRANSITION and then use an appropriate allowance again just for this kind of content change.

With regards to the changes via Item14048. Any kind of content change has to be covered by the access control system of the Foswiki core. This was fundamentally broken before 1.14. For instance topics not yet made publically available were still visible by searches and other plugins that - while interfacing with the core's access control system - did not interact with the specifics of the WorkflowPlugin as it was before, as it had its own access control implementation.

-- MichaelDaum - 10 Jul 2017

Actually it was still broken after 14048, as ACLs embedded in the topic text were not being rewritten, only those in preferences.

Yes, I understand your perspective, but there needs to be a more complete solution. Thinking about it. For now, I've made the enforcement of FW ACLs switchable in configure, as it breaks existing workflows in a way that's not easy to recover from.

-- Main.CrawfordCurrie - 10 Jul 2017 - 17:56

Addressed under Item14441

-- Main.CrawfordCurrie - 28 Jul 2017 - 19:23

Commenting is disabled while not logged in