Separate out chronology and enumeration

As of Jan 23, 2025 this can be considered “completed” currently awaiting the completion of https://folio-org.atlassian.net/browse/UISER-184 before this can be merged through

Nov 25, 2024

• TODO

  • Separate domain models for chronology and enumneration

  • Update services to use separate domain models

  • Add migrations (as cleanup) -

    • implementation to be discussed with @Ethan Freestone

    • functional testing of migrations to be tested by devs

    • migration testing outcome on Sunflower Bugfest environment (@Owen Stephens )

  • Update frontend to use revised domain models

  • Update (predicted piece set spec) integration tests and rulesets

• Review breaking change deployment process during code review- @Ethan Freestone

As it currently stands, when creating a new publication pattern all labelling rules (chronology and enumeration) are added to a single rules array within the template config. Within the backend this array is then separated into two individual arrays containing exclusively the enumeration and chronology in each in or for them to to be used within the templating engine i.e chronology1.year, enumeration1.level1 etc.

The proposed change is to separate out the templateConfig.rules array into individual chronologyRules and enumerationRules arrays (names subject to change), upon this change the frontend form would also be updated to reflect these changes.

This would pull the shape of the templateConfig inline with the templating engine format removing the need to separate out the rules array within the labelling service and will allow remove the necessity for dynamic class allocation within the templateplateMetadataRuleClass, which should reduce potential problems in the future with regards to editing the ruleset after saving. Furthermore it will also result in no longer needing special formatting functions on the frontend when transforming the saved JSON shape to the form values.

This would be considered a breaking API change as we would be changing the shape of the JSON being passed to the controller, additionally migrations would be required for separate existing templateConfig rules.