QA: 30/10

User does not have permission "ui-serials-management.rulesets.edit"

1. The Edit option should not be displayed at all. This follows the UX guideline to hide any elements which will never be active for the user.

User has the permission "ui-serials-management.rulesets.edit"

1. When the pattern has predicted piece sets.

• Edit option displays and is inactive.

2. When the pattern has no predicted piece sets.

• Edit option displays and is active.

• Pattern edit form is the same as the "New" pattern form.

• Label order is maintained.

  • Note: The combination rules were reordered when the form was edited. However, this also happens when a new pattern is created.

3. When Status is changed to "Active" and the pattern is saved:

   1. the saved pattern is made the Active one on the serial.

   2. AND the existing active pattern status is changed to "Deprecated".

      1. Note: the user is not informed via a toast that the pattern has been deprecated. Will create separate ticket for this.

   3. The pub pattern view displays rather than the Serial view

      1. Note: a new pattern should also follow this behaviour - instead the serial is displayed. Need a ticket for this.

Agreed between Owen/Gill 2nd Oct → we should offer two options in the Action menu:

1. Edit → this is visible in the Actions menu if the user has perms to edit, BUT it is only active as an option if the publication pattern is not linked to any predicted piece sets and the replaceandDelete option can be used. To the user this will look like an edit and no further explanation of the underlying mechanism is required in the UI. In this scenario the rulesetNumber should be copied along with the rest of the data so that when the user saves the new pattern it has the same number as the original, now deleted, pattern. The modal the user interacts with after choose “Edit” should be headed “Edit”

2. Copy and deprecate → this is visible in the Actions menu if the user has perms to edit and is always Active. This should be implemented instead of the “Create modified” in although the basic mechanism is the same but it uses the proposed replaceandDeprecate option. In this case there should be a new rulesetNumber for the new pattern. The modal the user interacts with after choose “Copy and deprecate” should be headed “Copy and deprecate”

• Test coverage > 80% achieved

• Mockups pending following UI/UX and language discussion

  • use Edit when ruleset not used

  • use Replace and Deprecate when ruleset is used

• UNKNOWN: Workflow use case: “duplicate and deprecate” / “clone”

  • is this needed? if so, is this work to do as part of this?

  • to follow up with in Slack

• Terminology to be clarified.

• TODO: new tests

• Need UI/UX input as to whether

  • single Edit option is sufficient

  • Edit labelling

  • how we feedback to users that a deprecated ruleset is in play

• See Slack thread for approach update: handle these through a replaceAndDelete and/or replaceAndDeprecate  endpoint.

• Approach

  • PUT endpoint for pattern needs to validate to prevent in-use pattern being edited

  • Check frontend form data is reversible

  • Add reverser for form

  • Determine how to decide whether Edit action is visible/active

  • Ensure order of rules are maintained

• Components and Changes

  • Frontend: new route for serials ruleset edit

  • Backend: custom binding, PUT endpoint validation

• Tests / Data / Dependencies

  • extend tests for ruleset form (for populated form with initial values)

  • new tests for new ruleset edit route component

• Known Unknowns

  • Check what happens when attempting to re-bind

  • Complexity with some reversal transformations, eg, dates

• QA: snapshot

• Release Target: Ramsons

• Development Estimate: