-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[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
Conversation
…dEvent::addTransitionBlocker()` instead.
There was a problem hiding this 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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since 4.4
There was a problem hiding this comment.
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
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 So Instead of removing the Could you update the PR? |
i see 2 issues with
For users or with implicit clear: |
I like this proposal |
I just looked at the code and As I said, I would like to avoid to add another deprecation. So the best option is to change the default message... |
@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 |
1 similar comment
@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 |
|
Closing in favor of #34573 |
…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
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.