[Workflow] Method buildTransitionBlockerList returns TransitionBlockerList of expected transition #28493
Conversation
Tetragramat
commented
Sep 17, 2018
| Q | A |
|---|---|
| Branch? | 4.1 |
| Bug fix? | yes |
| New feature? | no |
| BC breaks? | no |
| Deprecations? | no |
| Tests pass? | yes |
| Fixed tickets | #28432, #28429 |
| License | MIT |
| Doc PR |
…pected transition
|
Why it was not merged into 4.1 already? Is there some problem with this PR? |
|
ping @lyrixx |
There was a problem hiding this comment.
Thank you for this PR. Great that you added tests!
It is indeed a bug you've found. However, I'm not happy with the solution. It is correct, because transition names have to be unique for a place.
However I think a simpler solution would be:
if ($transitionBlockerList->isEmpty()) {
// We found a transition that we are allowed to do. Ie, we are not blocked.
return $transitionBlockerList;
}It works because the $marking->has($place) for all "froms" is already done in buildTransitionBlockerListForTransition.
If you make this update, then Im happy to approve this change.
|
I've found out that in case of state_machine transition names are not unique. At least that is how framework bundle generates transitons from configuration. see https://github.com/symfony/symfony/blob/v4.1.4/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php#L512 Your solution will not work correctly. Yes, you will get empty blocker list when expected to be empty, but in case of all blocked same name transitions, you will get wrong blocker list with wrong reasons why transition was blocked. Maybe I should add more test for this case. |
|
I tested only half of the issue. Now it should be fully covered. |
|
I have no idea where these failing tests came from, but it have nothing to do with my changes. |
|
Hm. Transition names are always unique from a place. Check the Validators. I need a whiteboard to figure this out properly. =) Since it is basically just you, (maybe I) and @lyrixx that understand this fix and the test after we look at it for 20 minutes, Could you add some more comments on your code change? Also a comment on the test to describe what they are testing? |
|
What validators I'm supposed to check? I see no workflow definition validators. I tried as hard as I could to make descriptions. I'm no good at explaining and english either. |
|
I agree with @Nyholm that having the |
|
Thank you for adding the comments and tests. What do you (@Tetragramat) think about @xabbuh's solution to the same problem? It makes the code a bit easier to follow, right? |
|
@xabbuh's solution looks better than my hotfix. |
|
@Tetragramat feel free to just copy the changes into your PR |
|
friendly ping @lyrixx |
|
Hello. Sorry for the very late reply. I will have a look tomorrow or after tomorrow. Thanks |
|
Hello, Thanks for you work. It's 👍 I made update the code to make it simpler in #29141 |
|
Closing in favor of #29141, thanks @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