Skip to content

[Workflow] Deprecate GuardEvent::setBlocked() method #34466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

jgallant
Copy link

Q A
Branch? 4.4
Bug fix? no
New feature? no
Deprecations? yes
Tickets
License MIT
Doc PR

GuardEvent::setBlocked appears to exist for backwards compatibility. If it is called externally, addTransitionBlocker is called with an 'unknown reason' message, which is difficult to debug. Deprecating setBlocked will help users call addTransitionBlocker instead.

Copy link
Contributor

@ro0NL ro0NL left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

THIS. :)

public function setBlocked($blocked)
{
@trigger_error(sprintf('The "%s" function is deprecated since Symfony 5.0, use "%s" instead.', 'setBlocked', 'addTransitionBlocker'), E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since 4.4

Copy link
Contributor

@noniagriconomie noniagriconomie Nov 20, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to process the string with sprintf and not write directly?

Feature related: « which is difficult to debug « transition blocker was aded after set blocked, and its aims is not for debug but more for end user app human understanding
For debug, i mean technical human, there is a trail logger iirc

@nicolas-grekas nicolas-grekas added this to the next milestone Nov 21, 2019
@lyrixx
Copy link
Member

lyrixx commented Nov 23, 2019

Hello @jgallant

Thanks for your first contribution.

Unfortunately, I would like to not add yet another deprecation. We have a solid upgrade path in Symfony, but deprecation are always boring to fix.

TransitionBlockerList was introduced to be able to attach a nice message from a guard when rejecting a transition to display it to the end user. During this work, I kept the setBlocked() method to keep the BC and also because it is possible to choose to not display a message to the end user.

So Instead of removing the setBlocked() method, I would instead change the default message to put something much more explicit and easier to debug.

Could you update the PR?

@ro0NL
Copy link
Contributor

ro0NL commented Nov 24, 2019

i see 2 issues with setBlocked;

  • the message is implicit, and not obvious to discover its root cause (a better message may help though)
  • the blocker list is implicitly cleared, which is a side effect

For users addBlocker($msg, $code) would be much appreciated, as keep doing $event->addTransitionBlocker(new TransitionBlocker($msg, $code)) becomes boring over time :}

or with implicit clear: setBlocker($msg, $code)

@lyrixx
Copy link
Member

lyrixx commented Nov 24, 2019

or with implicit clear: setBlocker($msg, $code)

I like this proposal

@lyrixx
Copy link
Member

lyrixx commented Nov 24, 2019

I just looked at the code and setBlocked(bool $blocked) accepts a bool. So we can not change change it to setBlocked($msg, $code) without a deprecation notice then BC Break (in SF 6.0).

As I said, I would like to avoid to add another deprecation.

So the best option is to change the default message...

@lyrixx
Copy link
Member

lyrixx commented Nov 24, 2019

For users addBlocker($msg, $code) would be much appreciated, as keep doing $event->addTransitionBlocker(new TransitionBlocker($msg, $code)) becomes boring over time :}

@fabpot What is your position concerning this kind of API? Should we stick to something really explicit, or could we add some shortcuts to make thing easier by hiding the reality. I know you already forbid $definition->addTransition('name', 'from', 'to') to keep $defintion->addTransition(new Transition('name', 'from', 'to')) so I think we should not add theses shortcut, But I understand it could be boring...

1 similar comment
@lyrixx
Copy link
Member

lyrixx commented Nov 24, 2019

For users addBlocker($msg, $code) would be much appreciated, as keep doing $event->addTransitionBlocker(new TransitionBlocker($msg, $code)) becomes boring over time :}

@fabpot What is your position concerning this kind of API? Should we stick to something really explicit, or could we add some shortcuts to make thing easier by hiding the reality. I know you already forbid $definition->addTransition('name', 'from', 'to') to keep $defintion->addTransition(new Transition('name', 'from', 'to')) so I think we should not add theses shortcut, But I understand it could be boring...

@nicolas-grekas
Copy link
Member

->setBlocked(bool, $msg = 'Some default') LGTM

@nicolas-grekas
Copy link
Member

Closing in favor of #34573
Thanks for raising the point.

fabpot added a commit that referenced this pull request Nov 24, 2019
…blocking a transition + better default message in case it is not set (lyrixx)

This PR was merged into the 5.1-dev branch.

Discussion
----------

[DX] [Workflow] Added a way to specify a message when blocking a transition + better default message in case it is not set

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #34466
| License       | MIT
| Doc PR        |

Commits
-------

169bb2f [Workflow] Added a way to specify a message when blocking a transition + better default message in case it is not set
@jgallant jgallant deleted the deprecate-workflow-set-blocked branch December 10, 2019 11:06
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants