Open alexander-schranz opened 4 years ago
I would propose to implement a TransitionFlushListener
(not sure about this name) that collects all workflow.[content workflow name].completed.[transition name]
events.
When doctrine emits a postFlush
event, we should emit a workflow.[content workflow name].flushed.[transition name]
event for each collected event.
This would allow projects to listen on the workflow.[content workflow name].flushed.[transition name]
event in the cases described in the issue.
just want to raise some attention for this issue, because that nearly stumbled us again ... @sulu/core-team do you agree on @nnatter's suggestion? I think it would be a good solution
The
ContentWorkflow
service allows to apply a transition on acontentRichEntity
and givendimensionAttributes
. For example, publishing the content of a specific language is possible by applying thepublish
transition of theContentWorkflow
.The
ContentWorkflow
service builds upon the Symfony Workflow component. Therefore, the service already emits various events when a transition is applied. These allow to execute additional logic when a specific transition is executed inside of a project.The existing events emitted by the
ContentWorkflow
service already cover a lot of cases. But in some cases it makes sense to execute the additional logic only if the changes of the transition are flushed to the database. For example, this makes sense when building a search index for some entity.Executing something only if a transition is flushed is a tricky problem because the
SuluContentBundle
does not flush anything to the database by itself, but relies on the project to flush changes at an appropriate time. Unfortunately, this makes it hard to use the events of theContentWorkflow
service in the cases described above.To solve this problem, we should implement a doctrine flush subscriber that listens to transition events and emits a new workflow event after the changes are flushed to the database (not sure about the naming.