Implement a confirmation form before the transition

This is what I could quickly build. It is not perfect, as I think the confirmation should be a full page confirmation (like ConfirmFormBase), but that would require a route and passing entities between forms. So for now, one just has to press the same button twice.

I have been breaking my head on this. To further improve this, I felt a full page confirmation form (using ContentEntityConfirmFormBase) would be nice. In my own custom module I have implemented that like this:

 * @ContentEntityType(
 *   ...
 *   handlers = {
 *     ...
 *     "form" = {
 *       "state_transition" = "Drupal\module\Form\StateTransitionConfirmForm",
 *     },
 *   },
 *   ...
 *   links = {
 *     "collection" = "...",
 *     "canonical" = "...",
 *     ...
 *     "state-transition-form" = "/module/{entity}/{field_name}/{transition_id}",
 *   },
 *   ...
 * )

This leads to paths that look like /module/123/field_state/accept, which I think is neat. The confirmation form then takes the field name and transition ID from the path; builds the form and performs the state change. The entity is available via ContentEntityConfirmFormBase and upon completion the user is redirected back the the entity's canonical display.

I am however struggling to find a way to somehow do this for all entity types, and I am in fact wondering if I should make the assumption to add a default route to all entity types, let alone redirect them to the canonical display.

Perhaps using a per-entity link template is not so bad?

Any advice would be nice.

Thanks for the guidance!

Give me a few days to untangle what I had built in a separate module.

Merge request opened (though I accidentally pushed to 8.x-1.x too, ignore that one).

I think that in commerce you'll need to define a link template and set the field formatter setting to 'require confirmation' and you are done. Form handler is optional and otherwise automagically added.

Link template:
* "state-transition-form" = "/order/{commerce_order}/{field_name}/{transition_id}",
Could be worth documenting... :)

Perhaps #2912849: Require confirmation for state transitions is a good issue for follow-up in commerce?

@jsacksick, Thanks for your work, luckily most of my effort was useable :). For my use case I needed view access permissions, but since state machine originally required the update permission I realized I needed to change it (but did it wrong). I tested in my development environment and faced no issues though, but that is probably on my end...

I have one remark; I see that you also changed the confirmation question and removed the entity label. I think that is a bit weird. Expecially in commerce where the transitions are not named 'Validate' or 'Complete', but instead they are 'Validate order' and 'Complete order' (which is better for on a button I think). But then the full question will become "Are you sure you want to Validate order?" I think it makes a lot of sense to add the order number (entity label) to the question. "Are you sure you want to validate order 123?" perhaps also transform the transition label to lowercase?

Other random examples such as "Are you sure you want to release [Random node title]?" or "Are you sure you want to promote [Username]?" do not look that bad either?

UPDATE
One remark, you validate transition id by '[a-z]+'. What about transition ID's with underscores that used to be valid?

I struggled with it too, for a while I've even used transition_id, entity_type_id and entity_label to build a sensible sentence... but faced issues with underscores there as well. So I agree there is no perfect solution.

You cannot use the entity ID in commerce. With the order numbers per store that will lead to lots of confusion and the numbers will not match, so you will have to use the label (or override the logic in commerce off course).

Option 4 still looks good enough to me, but I am not a native English speaker.
Option 5 would not work for me. I have an 'Accept on behalf of user' transition with id 'accept_on_behalf'. That transition will not pass anymore because of the underscores (mentioned in #15) and it will also look very weird in option 5.

I'd be inclined to say that the 'best' option would be to implement a transition suffix on the button, so you can name the transition 'Place' and still have 'Place order' on the buttons, but that will add complexity. Then you could ask ‘Are you sure you want to place the order?’

I was scanning over the code one last time, and overall I think this is a great improvement. But I just noticed that the field name was removed from the alterRoutes, hence my slow reply.

MY version:

          ->setRequirement('_entity_access', "$entity_type_id.edit")
          ->setRequirement($entity_type_id, '\d+')
          ->setOption('parameters', [
            $entity_type_id => ['type' => 'entity:' . $entity_type_id],
            'field_name' => ['type' => 'string'],
            'transition_id' => ['type' => 'string'],
          ]);

Your version:

        ->setRequirement('_entity_access', "$entity_type_id.update")
        ->setRequirement($entity_type_id, '\d+')
        ->setRequirement('transition_id', '[a-z]+')
        ->setOption('parameters', [
          $entity_type_id => ['type' => 'entity:' . $entity_type_id],
        ]);

Was this on purpose? The route does not make sense without a field name and the linkt template expects it.
And since the transition_id is regex, I was hoping to include underscores by changing it to '[a-z_]+'.

Apart from those nits, I am very happy for your fast repsonses as well.

I looked at all the routes defined in my codebase, I've never seen the following for string parameters.

Not sure where I've found it, but it did something; routes were invalid without.

Regarding the regexp, it perhaps would have made sense to allow underscores, and also do the same for field names.

Could you still commit it to dev? No need for a new tag (for me).

I'm just shutting down for dinner, I'll have a look later this evening.
Thanks for taking it into consideration.

Awesome, just tested and everything from my end works as expected. Thanks so much for for fixing and improving this 2 year old feature in several hours!