Grégoire Pineau
Contributed by Grégoire Pineau in #35322 , #34591 and #34573

Disabling announce events

The workflow.announce events are triggered for each transition that is now accessible for the subject.

In Symfony 5.1 you can disable those events using the context passed to the apply() method:

1
2
3
use Symfony\Component\Workflow\Workflow;

$workflow->apply($subject, $transitionName, [Workflow::DISABLE_ANNOUNCE_EVENT => true]);

Checking if a workflow exists

You can inject the Registry service to have access to all workflows defined in the application. In Symfony 5.1, this registry has added a new method called has() which checks if a workflow exists for the given subject:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
use App\Entity\BlogPost;
use Symfony\Component\Workflow\Registry;

public function myController(Registry $registry, BlogPost $post)
{
    // check if a workflow exists for this object
    if ($registry->has($post)) {
        // ...
    }

    // check if a workflow called 'publishing_workflow' exists for this object
    if ($registry->has($post, 'publishing_workflow')) {
        // ...
    }

    // ...
}

Explaining blocked transitions

In Symfony 5.1, when blocking a transition inside an event, you can now pass an optional second argument to setBlocked() with a message explaining why the transition was blocked:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\Workflow\Event\GuardEvent;

class BlogPostReviewListener implements EventSubscriberInterface
{
    public function guardReview(GuardEvent $event)
    {
        $blogPost = $event->getSubject();

        if (empty($blogPost->title)) {
            $event->setBlocked(true, 'This blog post cannot be marked as reviewed because it has no title.');
        }
    }

    // ...
}

If you don't provide a custom message, Symfony creates a generic message with the following syntax: "The transition has been blocked by a guard ($caller)."

Published in #Living on the edge