Closed (fixed)
Project:
Drupal core
Version:
8.5.x-dev
Component:
workflows.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
25 Jan 2018 at 23:39 UTC
Updated:
14 May 2018 at 12:29 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
kevin.dutra commentedHere's a test to help demonstrate the issue.
Comment #3
kevin.dutra commentedAnd now after augmenting the #delta.
Comment #4
sam152 commentedNice catch, bumping the available transition weights from 20 to 200 makes a lot of sense. A couple of things:
'#type' => 'weight'.Maybe something as simple as:
Comment #5
kevin.dutra commentedMy one reservation with allowing there to be more states is that it causes the number of possible transitions to explode farther, which is why I left that one as-is. Hopefully people aren't trying to create tons of states because it makes for a much more complicated process for the end users who are using it, but I suppose there might be the odd exception that actually requires something that complex. For now I think I'll leave that one alone.
I'm totally on board for the test refactoring. :)
Comment #6
kevin.dutra commentedComment #7
sam152 commentedLooks great, thanks.
Comment #8
alexpottWhy not count the number of transitions and use that? Any limit seems a bit arbitrary.
In blocks we do:
Comment #9
kevin.dutra commentedFair enough. Now it's dynamic based on the current number of transitions. I've gone ahead and added in a similar adjustment for states, as long as we're there.
Comment #10
runeasgar commentedTesting.
curl -l https://www.drupal.org/files/issues/2018-04-13/workflow-transition-ordering-2939634-9.patch | git apply -vdrush crMoving to RTBC.
Comment #11
alexpottCommitted and pushed 6a74240ce3 to 8.6.x and ffaf769407 to 8.5.x. Thanks!
Backported to 8.5.x as a bugfix.