- 🇮🇱Israel jsacksick
Currently, entity types can override the state transition confirm form via the entity type annotation... Isn't that sufficient?
Third party settings might make this more flexible, however this still requires writing a form alter, so I'm not sure what's the actual benefit of going with this approach instead? - Status changed to Needs work
over 1 year ago 11:16pm 24 February 2023 - 🇺🇸United States bradjones1 Digital Nomad Life
Currently, entity types can override the state transition confirm form via the entity type annotation... Isn't that sufficient?
I'm not actively implementing this quite yet, but I will point to my comment in #15 which I think addresses this; coupling the transition to the form API makes it harder to have a unified way of handling this "extra" information e.g. over JSON:API.
Third party settings might make this more flexible, however this still requires writing a form alter, so I'm not sure what's the actual benefit of going with this approach instead?
I'll only speak for myself where I think third-party settings aren't really the answer to the "extra transition data" question, which is why I renamed the issue.
Marking NW since a maintainer has chimed in with questions.
I am open to using a different method to collect additional data for a transition. For us, the important part is that some transitions should only be triggered programmatically, and others require custom forms (for example, if a user cancels an order, you may want to prompt the agent for why the order was canceled). Another advantage of documenting this in the workflow YAML instead of in code is it makes it easier to see the workflow in one place.
@bradjones1, you said you would want to use this feature request to trigger transition via the JSON:API and therefore didn't want this linked with the Form API. Can you tell me more about your use-case? Perhaps we can find a different way that would work for everyone.
- 🇺🇸United States bradjones1 Digital Nomad Life
Created a new issue forked off from this for being able to convey information in the transition (e.g., that can be accessed at runtime in event subscribers.)
- 🇷🇸Serbia holo96
+1 for this issue
Agreed with #18 and #19, forms are not always the use case.
Third party setting can be anything.
I needed to highlight some transition buttons for example.This can be achieved if you get it from workflow definition ($workflow->getPluginDefinition()) rather than creating plugin instance, but merging !7 would be more elegant solution.