This PR updates existing methods in the rule manager to create and update rule-tag relationships when the list of tags in a rule are specified.
Our rule methods will provide tags to the user as a list of ids as part of the rule data provided by our API.
The frontend maps these ids to a preloaded table of tags when providing tags as tag names in our frontend rule forms (and table).
The PR includes a database evolution:
draft rule-tag records now use the rule id as foreign key
live rule-tag records now use the external id & revision id as a foreign composite key
We've also increased the simultaneous connections in Postgres to get around an issue where we're running short of connections locally. This is a temporary workaround pending a proper fix.
How to test
Run the rule manager locally, including the tests. Do they all pass?
Also try creating, updating, and publishing rules. If you remove or add tags in these operations, do the changes persist as you'd expect?
Co-authored with @jonathonherbert
What does this change?
This PR updates existing methods in the rule manager to create and update rule-tag relationships when the list of tags in a rule are specified.
Our rule methods will provide tags to the user as a list of ids as part of the rule data provided by our API.
The frontend maps these ids to a preloaded table of tags when providing tags as tag names in our frontend rule forms (and table).
The PR includes a database evolution:
We've also increased the simultaneous connections in Postgres to get around an issue where we're running short of connections locally. This is a temporary workaround pending a proper fix.
How to test
Run the rule manager locally, including the tests. Do they all pass?
Also try creating, updating, and publishing rules. If you remove or add tags in these operations, do the changes persist as you'd expect?