Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Workflow] DeprecateGuardEvent::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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…dEvent::addTransitionBlocker()` instead.
ro0NL left a comment
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. :)
| */ | ||
| publicfunctionsetBlocked($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
noniagriconomieNov 20, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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
lyrixx commentedNov 23, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Hello@jgallant Thanks for your first contribution. Unfortunately, I would like tonot 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? |
ro0NL commentedNov 24, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
i see 2 issues with
For users or with implicit clear: |
lyrixx commentedNov 24, 2019
I like this proposal |
lyrixx commentedNov 24, 2019
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... |
lyrixx commentedNov 24, 2019
@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
lyrixx commentedNov 24, 2019
@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 |
nicolas-grekas commentedNov 24, 2019
|
nicolas-grekas commentedNov 24, 2019
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.