Require confirmation for state transitions

This is functionality we need to add to State Machine. We need to specify if a flow should have a confirmation form or just default to "all transformations get confirmation forms." Then we need to also patch Commerce to allow reversal transitions.

I do not see a problem with Canceled -> Draft reversal transitions. However, we do need a different ticket to discussed Completed -> reopened for RMA and such.

If someone is looking for simple confirm box this could be helpful.

function custom_module_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
  if (strpos($form_id, 'state_machine_transition_form_commerce_order_state_') === 0) {
    foreach ($form['actions'] as $key => $action) {
      if (isset($action['#type']) && $action['#type'] == 'submit') {
        $form['actions'][$key]['#attributes']['onclick'] = "return confirm('".$action['#value']->render()."? This action cannot be undone!');";
      }
    }
  }
}

Be careful when reversing states if transitions have any subscribed events. ie sending email, capturing payments,...

@maglaman I think it would be great to default to "all transformations get confirmation forms." or just have transitions as select options and submit button to confirm.

I'm actually going to elevate this feature to a higher priority, simply because it's way too easy right now to accidentally kill an order. I just did this in my local environment - was reading the state transition options, my brain first registered "C...." as "Complete", and I couldn't prevent the cancelation. Once it was canceled, I couldn't reopen it.

I know this is a tricky thing, because we don't always know if a state transition would be reversible or not. For example, a transition that might ordinarily be reversible in any given site may have an event subscriber that implements some automated process based on a particular transition. However, it ought to be possible to identify a non-reversible state transition and require a confirmation for it.

I tend to think this should be in a modal dialog - no need to load an intermediate page, especially if someone wants to cancel the transition due to an accidentally button click. The form would also be an appropriate place for people to alter fields specific to the transition (e.g. you might have some optional email event associated with a particular transition and could include a checkbox to enable it for that particular operation).

As to whether or not this needs to happen upstream in State Machine, I'm divided. I think I understand the rationale, but because this is likely to be so specific to order workflows (and almost certainly a different UX than #3051503: Implement a confirmation form before the transition is currently proposing), I'd be interested in brainstorming how to make this a part of Commerce Order itself.

I like the idea of adding optional confirmation forms. Currently I use Guards a lot to prevent transitions that shouldn't happen yet, but that doesn't help for the scenario Ryan just described. I don't think we want to make confirmations required for all transitions, since if there are reversal transitions, confirmation might not be necessary.

If we do make this change upstream in State machine, I think it would be great if it was part of the workflow yaml definition, so instead of:

    cancel:
      label: 'Cancel order'
      from: [draft, processing]
      to:   canceled

You could have this to indicate that confirmation is required for transitions through the admin UI:

    cancel:
      label: 'Cancel order'
      confirm: TRUE
      from: [draft, processing]
      to:   canceled

Then the StateTransitionForm used by the field formatter could alter the submit response based on that "confirm" value.
I just stumbled on this somewhat related Core issue: https://www.drupal.org/project/drupal/issues/2883755. There's no work in progress there, but there are links to a couple other modal/confirmation issues there.

We'll need to implement this in state machine. Or add our own abstraction in commerce.

This is already present in the state machine queue as issue #3051503: Implement a confirmation form before the transition with a quick POC. In the meantime I have prepared a better solution in another module inheriting the state change form.

I will attempt to port it to state machine.

#3051503: Implement a confirmation form before the transition was committed and a new State machine release was tagged.

The attached patch should do it, though curious to see which tests are failing (suspecting some will).

Bumping the State machine requirement to 1.2 although we probably need actual test that ensures a confirmation form is presented.

So confirmation will be required for all state transitions on new installs. This is a formatter setting and can be disabled anytime.

Also, entity types (like orders) have a way to specify a "state-transition-confirm" form class to override the default state machine confirmation form if necessary.

Do you need an update hook to update existing installations too?

Nope, only changing that on new installations on purpose... People are free to decide whether they'd like to require the confirmation or not.

would be great if that feature is pointed out in the release notes :)

I am experiencing issue after this update.

Go to Shipments tab > click cancel shipments button
Go to View tab > click fulfill order
Previous and expected behavior is that order moves to completed state and no shipping confirmation is sent out.
After this update, order moved from Fulfillment to Completed by the Fulfill order transition and confirmation shipping email is still sent out, even though shipment was cancelled.

This is not directly related to this issue, as here only the order entity is updated to work with the state machine updates. It is most likely also not #3051503: Implement a confirmation form before the transition, as the behavior should not have changed when there is no link template defined.

My best guess would be #3083407: Fire intended events when invoking a specific transition, but then the old behavior would actually have been a bug.

It is also a good trigger that shipping probably will need a similar update to the entity as done here.
Created #3219675: Require confirmation before applying state transition for shipments.

I need to clarify my #20 above - it is the shipping email that goes out after I cancel the shipment and then click on fulfill order.
This happened after making the state_machine update.

@djween: hm... What you're describing seems to be related to #3083407: Fire intended events when invoking a specific transition.

The transition is technically not allowed and it shouldn't be applied... But this should be reported in the State machine issue queue.

@djween: Just to make sure, previously the shipment state was still updated but the confirmation wasn't sent, correct?

I am curious why a an order with no shipments runs in a shipping workflow. If there is no product to be shipped, then the workflow is wrong by design?

I think it makes sense that a workflow with shipping should block if the shipment is not performed.

@djween: Could you check if #3219843: Ensure shipment transitions are allowed before applying them is doing the trick for your particular shipping issue?

@jsacksick, @Neograph734
I opened new issue in State machine queue and answered 24-26 there:
https://www.drupal.org/project/state_machine/issues/3219913

Hey Guys,

After updating to the latest commerce version we are getting these errors:

The transition "place" is currently not allowed. (Current state: "draft".)

They are caused when anonymous people are placing order aka paying for it.... This new Workflow steps seems to be interfering...

Has anyone know how this validation can be bypassed when we trigger workflow transitions using code?

Cheers

are you using a custom workflow? then you have to check the transitions. compare with the shipped ones from Commerce

@Povilas Uogintas, you can no longer jump to a state that is not allowed from the current state. So if your workflow requires validation, you should also do the validation step in your code (you can't jump from draft to complete anymore).

It is explained in this state machine change record:
https://www.drupal.org/node/3220507

Hey guys, thanks! Yes I am using custom workflows for instance here is my workflow:

order_normal:
  id: normal_order
  group: commerce_order
  label: 'Default Order Flow'

  states:
    draft:
      label: 'Draft'
    verification:
      label: 'Verification'
    shipment:
      label: 'Shipment'
    shipmentfail:
      label: 'Shipment Failure'
    pending_payment:
      label: 'Pending Payments'
    fulfillment:
      label: 'Fulfillment'
    completed:
      label: 'Completed'
    canceled:
      label: 'Canceled'

  transitions:
    place:
      label: 'Place order'
      from: [draft, pending_payment]
      to: shipment
    payment_required:
      label: 'Issue Payment Requirement'
      from: [draft]
      to: pending_payment
    verify_fail:
      label: 'Verification Failed'
      from: [draft, shipment]
      to: verification
    verify_success:
      label: 'Confirm Order'
      from: [verification]
      to: shipment
    ship:
      label: 'Ship order'
      from: [shipment]
      to: fulfillment
    fulfill:
      label: 'Fulfill order'
      from: [draft, shipment, shipmentfail, fulfillment]
      to: completed
    cancel:
      label: 'Cancel order'
      from: [draft, shipment, shipmentfail, verification, fulfillment, pending_payment]
      to: canceled

you can clearly see that transition "place" is allowed to be triggered from Draft to Shipment. But the site still triggered error. Which does not really make sense... I added a patch currently to ignore this but trying to do debugging to figure out what is actually causing this as everything seems to be valid.

At a first glimpse it looks like it should work, but it could be a state machine guard blocking this, or perhaps a permission? But please create a new issue for this is you need support (link here if relevant). This issue is closed and is not intended for follow-up support.
Furthermore, if this is indeed a bug, it is more likely to be related to the state machine module than to commerce.

Try to provide as clear steps as possible. Use the method in the earlier linked change record to see if the transition is allowed. Try with a default commerce workflow to see if the problem occurs there as well, etc.

Sorry for the stupid question, but how can I disable state machine confirmation form

If you edit the form display of the order type, you should be able to edit the state transition form settings. There you will find a checkbox to enable and disable the extra confirmation.

Thank you