Details
-
Bug
-
Status: Closed (View Workflow)
-
P2
-
Resolution: Done
-
None
-
-
eHoldings Sprint 128, eHoldings Sprint 129, eHoldings Sprint 130
-
3
-
Spitfire
-
R3 2021 Bug Fix
Description
Overview:
Each time POST /_/tenant called a new portion of default mapping rules is saved to the database. This may cause that not last updated rules will be used for records mapping.
Steps to Reproduce:
- Call POST /_/tenant on an empty database
- Call POST /_/tenant one more time
Expected Results: 1 rule per record type in the database
Actual Results: 2 rules per record type in the database.
Open questions:
- Should the module replace already existing mapping rules for default when the module is updating to a new version?
- We should clear the database from extra rules that have already been saved to the database. But due to database structure, we couldn't detect which rule is last updated. Will it be a big problem if we save default rules to the database instead of already existing?
Approach:
- Clear database from existed rules. (depends on the answer to the 2nd question)
- Modify database to have a unique constraint for `record_type` column.
- Modify logic of saving rules. Depends on the answer to the 1nd question:
- Replace existing rules with default ones.
- Don't save default rules if rule for recordType already exist in database
TestRail: Results
Attachments
Issue Links
- defines
-
UXPROD-3333 Lotus release -Spitfire - Technical debt
-
- Closed
-
- relates to
-
MODSOURMAN-744 mapping_rules migration fails on missing "mappingRules" property
-
- Closed
-
-
MODSOURMAN-632 Create a script to delete duplicate mapping rules for each record type
-
- Closed
-