[Workflow] Fixed bug of buildTransitionBlockerList when many transition are enabled#29141
[Workflow] Fixed bug of buildTransitionBlockerList when many transition are enabled#29141lyrixx merged 2 commits intosymfony:4.1from
Conversation
lyrixx
commented
Nov 8, 2018
| Q | A |
|---|---|
| Branch? | 4.1 |
| Bug fix? | yes |
| New feature? | no |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | #28429 #28432 #28493 |
| License | MIT |
| Doc PR |
…pected transition
cb5d853 to
8a68a05
Compare
| // marking. Because it means the marking was OK Transition are | ||
| // deterministic : it's not possible to have many transition enabled | ||
| // at the same time that match the same marking with the same name | ||
| if (!$transitionBlockerList->has(TransitionBlocker::BLOCKED_BY_MARKING)) { |
There was a problem hiding this comment.
We could update the condition above: if ($transitionBlockerList->isEmpty() || !$transitionBlockerList->has(TransitionBlocker::BLOCKED_BY_MARKING)) {
There was a problem hiding this comment.
But then the comment will be harder to understand because it applies to only one part of the if statement
I prefer to keep it as it. Are you OK with that?
| $this->blockers[] = $blocker; | ||
| } | ||
|
|
||
| public function has(string $code): bool |
There was a problem hiding this comment.
Should we mark this method as internal?
There was a problem hiding this comment.
It could be usefull to any one, isn't?
We could mark it internal, but I don't really see benefit of doing it.
It will update the code if you want.
| { | ||
| $transitions = $this->definition->getTransitions(); | ||
| $marking = $this->getMarking($subject); | ||
|
|
|
|
||
| // We prefer to return transitions blocker by something else than | ||
| // marking. Because it means the marking was OK Transition are | ||
| // deterministic : it's not possible to have many transition enabled |
| } | ||
|
|
||
| // We prefer to return transitions blocker by something else than | ||
| // marking. Because it means the marking was OK Transition are |
There was a problem hiding this comment.
I don't understand this sentence. I don't get the subject of "are".
8a68a05 to
732f343
Compare
|
@fabpot Thanks for the review. I have addressed your comments. |
|
Thanks for fixing this bug @Tetragramat. |
…ny transition are enabled (Tetragramat, lyrixx) This PR was merged into the 4.1 branch. Discussion ---------- [Workflow] Fixed bug of buildTransitionBlockerList when many transition are enabled | Q | A | ------------- | --- | Branch? | 4.1 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #28429 #28432 #28493 | License | MIT | Doc PR | <!-- Write a short README entry for your feature/bugfix here (replace this comment block.) This will help people understand your PR and can be used as a start of the Doc PR. Additionally: - Bug fixes must be submitted against the lowest branch where they apply (lowest branches are regularly merged to upper ones so they get the fixes too). - Features and deprecations must be submitted against the master branch. --> Commits ------- 732f343 [Workflow] Made code simpler db69ccc method buildTransitionBlockerList returns TransitionBlockerList of expected transition
|
Has this been fully fixed? This change |
|
Comments on merged pull requests are likely to get lost. Please open a new issue if you think something is wrong and provide a small example application to reproduce it. |