Adds a publish history to our rules, and displays it in the UI.
Nothing published yet
Published
Subsequent revisions
We now keep every live rule we ever write, but ensure that only one is active at a given time.
In the database, we model this by removing the unique constraint on external ids for our live table, and adding a constraint for (external id, revisionId), to ensure that it's not possible to write the same rule and revision multiple times. We then add another property to the live table, is_active, with a unique constraint on is_active that only applies when is_active is true, to prevent more than one live rule being active at a time.
Our rule/:id endpoint then serves both the current draft rule and the rule history on every read.
On the frontend, I've refactored a bit to move the 'create rule' button out of the rule form itself, and abstracted the individual rule fetch logic into its own hook, to separate the concerns of fetching, managing the form open state, and the form itself.
As a result, this PR is a bit larger than expected! The server-side and client-side commits should be well separated, but I'm happy to split this into two PRs if it'd be easier to review. One advantage of keeping just one PR – it's easier to verify that the publish logic is working as expected.
How to test
The automated tests that have been adjusted for publication and the active state, and the new tests for getting rule data, should pass.
We don't yet have a publish button – this will come with its own server-side validation logic, so I thought given the size of this PR it'd be better to ship that separately. In its absence, publish rules per the guidance in #324:
Publish a rule successfully, and the live version should appear in the rule history
Attempting to publish a rule again should result in an error (you cannot publish the same rule twice)
Editing that rule to give it a new revisionId should allow it to be published again. The new version should appear in the publication history.
Examining the history of the rules pulled in from the sheet by clicking the 'refresh' button should show that they've been created by the sheet (per the second screenshot above)
Thanks for spotting the validation errors, the refactor of the form was more substantial than I initially intended! bf414b26dd0960001de9a28eeda3f5c1bc0ffe20
What does this change?
Adds a publish history to our rules, and displays it in the UI.
We now keep every live rule we ever write, but ensure that only one is active at a given time.
In the database, we model this by removing the unique constraint on external ids for our live table, and adding a constraint for (external id, revisionId), to ensure that it's not possible to write the same rule and revision multiple times. We then add another property to the live table,
is_active
, with a unique constraint onis_active
that only applies whenis_active
is true, to prevent more than one live rule being active at a time.Our
rule/:id
endpoint then serves both the current draft rule and the rule history on every read.On the frontend, I've refactored a bit to move the 'create rule' button out of the rule form itself, and abstracted the individual rule fetch logic into its own hook, to separate the concerns of fetching, managing the form open state, and the form itself.
As a result, this PR is a bit larger than expected! The server-side and client-side commits should be well separated, but I'm happy to split this into two PRs if it'd be easier to review. One advantage of keeping just one PR – it's easier to verify that the publish logic is working as expected.
How to test
The automated tests that have been adjusted for publication and the active state, and the new tests for getting rule data, should pass.
We don't yet have a publish button – this will come with its own server-side validation logic, so I thought given the size of this PR it'd be better to ship that separately. In its absence, publish rules per the guidance in #324: