Plone.app.workflowmanager - worth it?

Plone Support Add-on Development
1

I wanted to try out the add-on and immediately hit problems.
I'm not asking for fixes (I can do that) - I'm just wondering if it's worth it.

We're going to push out a fairly disruptive, but hopefully beneficial update to start enforcing some permissions and workflow upon our users. But we also want to have a light touch, so being able to easily review a workflow and edit it - avoiding massive productivity disruptions and rollbacks - is a must.

It looks like plone.app.workflowmanager is really a must-have.
Even if only the workflow visualization works, that's a huge benefit.

Is it actually worth it to spend my time fixing this up for us (and everyone)? Be Honest.

I know it's great for Plone to keep these add-ons working, but I need to justify my time to my employer. I'm on the fence here and it feels risky to dive into this.

------------------- Dev Notes ----------------

Plone 5.2.4 (5212)
CMF 2.5.0
Zope 4.5.5
Python 3.8.10 (default, Nov 26 2021, 20:14:08) [GCC 9.3.0]
PIL 6.2.2 (Pillow)
WSGI: On
Server: waitress 1.4.4

From PyPi (just adding the egg to buildout) gives python 3 errors when starting the server instance.
ImportError: cannot import name 'urlencode' from 'urllib'
from sets import Set

Started poking at this, but found that @thet created a py3 branch (yay) and tried that but couldn't get the plugin to install. I didn't like the look of this rabbit hole:

Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 162, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 371, in publish_module
  Module ZPublisher.WSGIPublisher, line 266, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module Products.PDBDebugMode.wsgi_runcall, line 60, in pdb_runcall
  Module Products.CMFPlone.controlpanel.browser.quickinstaller, line 689, in __call__
  Module Products.CMFPlone.controlpanel.browser.quickinstaller, line 454, in install_product
  Module Products.GenericSetup.tool, line 399, in runAllImportStepsFromProfile
   - __traceback_info__: profile-plone.app.workflowmanager:default
  Module Products.GenericSetup.tool, line 1483, in _runImportStepsFromContext
  Module Products.GenericSetup.tool, line 1295, in _doRunImportStep
   - __traceback_info__: jquerytools-various
  Module plone.app.jquerytools.setuphandlers, line 24, in importVarious
  Module plone.app.jquerytools.setuphandlers, line 10, in disable_css
  Module Products.CMFCore.utils, line 13, in check_getToolByName
  Module Products.CMFCore.utils, line 139, in getToolByName
AttributeError: portal_css
1 Like
2

At least @tkimnguyen thinks its useful :wink: GSoC 2022 brainstorming - #9 by tkimnguyen

1 Like
3

It didn't work with Plone 5.2. The drawing library is old. Needs (re?) work.

4

It is a great tool! It really should be there in everyone's installation.

5

I am pretty sure I used it recently with this branch GitHub - plone/plone.app.workflowmanager at py3-ale

2 Likes
6

Looks like before any work can be started, the branch mess needs a cleanup :wink:

7

plone.app.workflowmanager provides a super useful feature IMO. I updated the package in recent years every now and then to show it to clients for pitches. I also tried to clean up the branch mess and make a proper release. Lots of people put effort into trying to upgrade the package to Python 3 and stuff. Though, to be honest this feels like a lost cause to me and I would rather recommend starting over from scratch.

I started to write a workflow manager in JavaScript a few years ago (actually multiple different approaches) and there are lots of modern JS libraries that allow you to create graphs. Though the workflow use case we have is non-trivial and it is not easy to find a library that does everything we need.

I would love to see some initiative (maybe a GSoC) project that creates the necessary restapi endpoints and then builds a modern solution on top of that for Plone 6 / Volto. In theory, such a solution could be backported to Plone Classic but I would not recommend it. Making modern JS libraries work with an outdated JS stack is one of the worst tasks one could choose (and yes, that's still true with the updated JS stack we have for Plone 6 classic, we still have jQuery and other ancient libraries in there that will cause pain and will not work with React or any other modern Framework that needs control over the DOM).

I'd be happy to give some guidance if anyone would want to approach this.

4 Likes
8

This doesn't look hard. If we assume py3-ale is working well.

9

Since we (my organization) are pushing a workflow initiative here, and pushing a headless initiative, this is aligning with our needs well right now.

The immediate deliverable for us is a Plone 5.2 view - so that's definitely p.a.workflowmanager for now. I'm not willing to sell a business workflow change bundled with a Plone 6 upgrade story. I'd rather deliver workflow now to prove Plone5, then sell a Plone6/volto story afterward - which turns the existing workflow headless.

If I'm reading you correctly, the Plone6 solution would only be API endpoints and a new JS frontend. This would end-of-life p.a.workflowmanager as it exists today, or at least only be supported as a classic-ui add-on.

I thought about p.a.workflowmanager adding the needed restAPI endpoints, and quickly decided that's a bad idea. It feels like a core enhancement. But that's me.

10

FTR: There is also my ages old collective.wfautodoc · PyPI which is just a dumb simple Graphviz visualization of workflows and ZMI bound only. I build it for documentation purposes only. But it still works and I upgraded it for 5.2/py3 (untested in 6 - but at ZMI level not much changed).

1 Like
11

Probably completely off topic, but I remember from some time ago that I looked into making diagrams with markdown.

I found some python markdown extensions that had 'extremely simple syntax to generate diagrams and worked with Plone 5.2

I am not sure what js was used, but I think it was flowchart.js ( flowchart.js ?)

12

@flipmcf @alert
I merged this branch with the PR https://github.com/plone/plone.app.workflowmanager/pull/71 into [WIP] Python 3 compatibility by thet · Pull Request #70 · plone/plone.app.workflowmanager · GitHub.
Everything is now at: GitHub - plone/plone.app.workflowmanager at py3

2 Likes
13

Hiya,

as an alternative - you could consider GitHub - 4teamwork/ftw.lawgiver: Generate Plone workflows by simply describing them in a human readable language.. It doesn't produce diagrams, but it DOES produce workflows in very readable language that can realistically IMO be understood by non-technical stakeholders. See an example here. It needs a little adjustment from standard workflow thinking see their "action group" definition, but not much. And workflows can then be committed to sourcecontrol in a readable format.

3 Likes
14

The use case for p.a.workflowmanager is to allow someone to build a workflow via the UI. Documenting a workflow is subset of its capabilities

1 Like
15

Sounds like a great project and very useful for Plone.
I guess one GSOC project should probably first focus on the backend part, as both might be to much and we and up with something half and unuseable. But if we have the endpoints, others can follow and build UI's for it.

2 Likes