Description
The way the client is designed, it gets the workflow definition from GET /api/travel-request/. If there's an id property, it renders the data and the events. If there's multiple state.actions, it renders action buttons. If there's only 1 state.actions, it renders the form for it. If there's more than 1 state.actions, it waits until you select one of the action buttons, and renders that form. On submission, the form posts to POST /api/travel-request/<case-id?>/<action-slug>?token=xx.
At the moment, this fails on the initiate action, I think because by design we expected clients to not include the action on the initiate POST. But it's actually pretty simple to do that since (a) we're providing the name of the action in the response to their GET request, and (b) they're already using part of that response for their POST request (the template).
My guess is you probably added extra logic to identify what the default action was. Perhaps this isn't necessary, and we can just expect clients to include the action name in every POST request.
Thoughts @mjumbewu ?