Ideally we would like users to only progress through the journey using the workflow state machine. Clicking "submit" sends you to the next page. Clicking "back" sends you to the previous page. Both of them trigger an AASM event which transitions the record between two different states in an approved way.
But this isn't realistic – if we lock users into this behaviour and force them to only view what we think is the "correct" form (the one saved as the workflow_state) then this makes the browser back button unusable.
As a result we introduced the concept of "flexible navigation" – basically, is a user allowed to view this form out of sequence? For most forms, this is the case. The only exception is forms where we want to confirm the user has absolutely gone through the process and entered the required data - things like the "declaration" or "registration complete" pages.
However, all "flexible navigation" logic is totally unrelated to the workflow state machine.
In WEX, whether a form is "flexible" or not is currently set using a method on the form model. WCR has an older iteration which relies on whether or not the model includes a concern. In both engine, the checks are called from the FormsController, which then loads or redirects a form depending on the result (and resets the workflow_state to the one the user is actually on).
This causes a lot of confusion for anyone who is introduced to the codebase, especially as testing of the two concepts is often interlinked.
I would like to see if we can clarify this division of responsibility somehow, either through refactoring or some sort of improved documentation.
Ideally we would like users to only progress through the journey using the workflow state machine. Clicking "submit" sends you to the next page. Clicking "back" sends you to the previous page. Both of them trigger an AASM event which transitions the record between two different states in an approved way.
But this isn't realistic – if we lock users into this behaviour and force them to only view what we think is the "correct" form (the one saved as the
workflow_state) then this makes the browser back button unusable.As a result we introduced the concept of "flexible navigation" – basically, is a user allowed to view this form out of sequence? For most forms, this is the case. The only exception is forms where we want to confirm the user has absolutely gone through the process and entered the required data - things like the "declaration" or "registration complete" pages.
However, all "flexible navigation" logic is totally unrelated to the workflow state machine.
In WEX, whether a form is "flexible" or not is currently set using a method on the form model. WCR has an older iteration which relies on whether or not the model includes a concern. In both engine, the checks are called from the FormsController, which then loads or redirects a form depending on the result (and resets the
workflow_stateto the one the user is actually on).This causes a lot of confusion for anyone who is introduced to the codebase, especially as testing of the two concepts is often interlinked.
I would like to see if we can clarify this division of responsibility somehow, either through refactoring or some sort of improved documentation.