Support third-party settings on transitions

Created on 19 August 2016, over 8 years ago
Updated 5 April 2024, 9 months ago

Moving #2757317-7: Provide field formatter to provide transitions as actionable buttons by @dimilias to its own issue, and adding form mode integration

Like Jira, it would be nice to have a transition form. Not something outrageous but like jira does, if every transition had something like the following:

transitions:
    draft:
      label: Create
      from: [__new__]
      to: draft
    propose:
      label: Propose
      from: [__new__, draft, validated, in_assessment, proposed]
      to: proposed
      transition_form_mode: core.entity_form_display.submission.reason_form.default
    validate:
      label: Validate
      from: [__new__, draft, validated, proposed, deletion_request]
      to: validated

The form mode reason_form might have form fields in it roughly like:

fields:
          field_test_body:
            required: false
          field_test_reason_to_propose:
            required: true

then you would be led in a custom edit screen of the entity with these two fields (one required and one not) and upon submit, entity would be updated including the state.

Don't know if its feasible to show this form when a transition is initiated view Views Bulk Operation.

Feature request
Status

Needs work

Version

1.0

Component

Code

Created by

🇺🇸United States moshe weitzman Boston, MA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇮🇱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 almost 2 years ago
  • 🇺🇸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.

Production build 0.71.5 2024