kaliop-uk / ezworkflowenginebundle Goto Github PK

Might be cached in stash or possibly the sf cache?

Title says it all

By hooking up into kaliop kueueing bundle

ezworkflowenginebundle is installed under ezp6.
A workflow is configured for publishing content by publish date.
When content is published with publish date in future the content gets visibility "hidden". When publish date is reached and workflow is resumed the visibility of the content is set to "visible" in database (ezcontentobject_tree table). In the backend the content is still labeled as "hidden". Moreover the content isn't visible in frontend until cache is purged manually.

We have some strange behavior after upgrading to version 1.1.0. We are not able to publish any content, even if the is no yml file in the defintion folder.

the comand line tools thrwos this error:
[Symfony\Component\Debug\Exception\FatalThrowableError]
Type error: Argument 1 passed to Kaliop\eZWorkflowEngineBundle\Core\StorageHandler\Database\Workflow::__construct() must be an instance o
f Kaliop\eZWorkflowEngineBundle\Core\StorageHandler\Database\DatabaseHandler, instance of eZPublishCorePersistenceDoctrineConnectionHandl
er_0000000016addadb00000000796a17a53e15d0cd5188c906535c81cc78ea2558 given, called in /var/www//htdocs/app/cache/prod/appProdProjectContainer.php on line 4237

Seems there is some trouble withe the changes in database constructor.
We are ussing ezpublish-kernel 6.13.2

It could be useful eg. for an 'audit log' workflow step

Error while cleaning the prod cache in ezpublish-kernel 7.1
In AbstractRecursivePass.php line 158:

Invalid service "ez_workflowengine_bundle.workflow_service.facade": method "Kaliop\eZWorkflowEngineBundle\Core\WorkflowServiceFacade::addDefinitionParser()" does not exist.

While referencing functions addDefinitionParser and addExecutor from ezmigrationbundle/Core/MigrationService.php it works fine

Off the top of my head:

• workflow defs loader and parsers
• a cli command to list workflow definitions
• slot event listener which creates and runs a migration if a corresponding definition is found, setting the slot parameters as references
• a workflow step 'filter' which cancels execution if a set of conditions is not matched
• a different set of events for workflows than the ones used by std migrations (or just no events at all ?)
• injecting the sf logger into the workflow service to allow troubleshooting workflows (instead of a logging-listener as is done for migrations)
• a cli command to list executing/failed/cancelled workflows
• a cli command to clean up the workflow tables from executed and cancelled workflows
• a way to prevent ez slots to be triggered recursively from within workflows if required

It would be nice to be able to keep the current user logged in, but allow him to do stuff with super-user powers