Item13307: Multiple issues with WorkflowPlugin

1. it doesn't really use ACLs to protect unauthorized edits
   • No idea what you mean by this - C.
   • WFP intercepts any edit not authorized in a current state. However it does not rely on Foswiki's ACLs to do so. Instead it throws an exception in an edit-related plugin handler. This isn't robust enough which for example is causing the error next in the list letting you rename/move a topic nevertheless. Also: any other component won't be able to check for change access such as hiding the edit buttons for the topic in case you are not allowed to edit anyway. WFP should be reworked to automatically maintain the ACLs of a controlled topic according to the workflow definition and let the Foswiki engine just do its job. - MD.
2. you can rename a controlled topic that you don't have edit rights for according to the workflow
   • OK, that needs it's own Task - C.
3. formatting history is way too difficult using a separate WORKFLOWHISTORYFORMAT preference settings for the WORKFLOWHISTORY macro
   • Agreed - C.
4. %META:WORKFLOW{}% is redundant 100%: all info is already listed in %META:WORKFLOWHISTORY (LASTTIME_xxx, as well as the current state)
   • I was trying to get rid of WORKFLOWHISTORY but it's hard, due to compatibility constraints - C.
   • META:WORKFLOWHISTORY is just fine: one record per history entry. META:WORKFLOW is wrong as all of its information can be extracted from META:WORKFLOWHISTORY. META:WORKFLOW is not able to cover all of the information stored in META:WORKFLOWHISTORY. The way this is done right now (using custom LAST_state_xxx attributes) is flawed by design in the sense of modelling a list of things stored in Foswiki's META:xxx format. - MD.
5. there is no way to get the message of some arbitrary state
   • OK, that needs it's own Task - C.
6. custom %WORKFLOW_ (e.g. %WORKFLOW_NOTICE) aren't always resolved, see the provided examples
7. editing an approved topic doesn't unapprove it, a required feature, imho
   • There's no particular predefined semantics defined for any named state. Agree that this is a desirable enhancement, needs it's own Task - C.
8. changing the form as part of a state transition always drops the user into edit mode ... would be nice not having to
   • Agree that this is a desirable enhancement, needs it's own Task (note that it's quite tricky to do, due to the Save semantics) - C.
9. no way to customize the output of WORKFLOWTRANSITION; the input elements are hard-coded
   • Agree that this is a desirable enhancement, needs it's own Task - C.

-- MichaelDaum - 16 Mar 2015

Added some comments above. I'm more than happy for anyone to tackle implementations/fixes - WorkflowPlugin is a collaborative work.

-- CrawfordCurrie - 19 Mar 2015

Commenting is disabled while not logged in