The intricacies of a ‘minor’ change
We’ve had plenty of changes to the forms while developing the Business Grants Portal (BGP). We knew that the forms would continue to change even after the site is live, but we did not design BGP for arbitrary changes to avoid over-engineering it. For those unfamiliar with BGP, it’s basically a bunch of webforms for businesses to apply for Government grants. Do check out this brilliant piece by my colleague Yang Zi if you want to know more about BGP.
The first change to the form is deceptively simple: Adding a paragraph to the user agreement clause. If this form was not in production yet, a simple change in the en.yml file would’ve done the job.
But now that it’s already in use, we need to make sure that the new clause only shows up for new grant applications, so that we do not change what earlier applicants agreed to. Earlier submissions still need to display the old agreement clause. It’s just like paper forms. Once you get a form it never changes, and when you get a new form you get the latest version.
First attempt — go by draft creation time
For this approach, users who started on the form before the cut-off will always see the old clause, even if they submit after the cut-off date. This doesn’t work as we only want users to submit with the new agreement clause.
Second attempt —look at the current time
To ensure that users see the correct agreement clauses, we could decide at load time what to display to the users. Forms loaded before the cut-off would display the old clause, while forms loaded after the cut-off shows the new version. This way it doesn’t depend on when the draft was created. Oh wait… but what if a user loads the form before the cut-off, but only submits it after?
Third attempt —a special cut-off time
To avoid the above scenario, we just need to make sure that no user sessions survive the cut-off time. That way, no users would be able to load the page before the cut-off and still be able to submit after. Good thing there’s a scheduled downtime coming up, so we can use that as the cut-off time for the changing the agreement clause, and terminate all user sessions during that time.
Final thoughts
This solution is not fool-proof though. A rogue user could still see the old agreement clause after the cut-off by simply changing his system clock. But we have measures in place to handle this in the backend.
This was a fun little exercise hidden in the seemingly boring task of building web forms.
Do you have a better way of handling web form versioning? Leave a comment below or contact me at chai_sheng_hau@ida.gov.sg. Would love to hear from you!
