[User Story]: Trigger identifier renaming manually

[cptanalatriste]

Role

As an Assurance Case Designer

Desired Feature

I want to trigger identifier manually, instead of automatically

Benefit

So that I can take actions before renaming happens.

Acceptance Criteria

GIVEN that I've added removed case items AND their names are inconsistent WHEN I click the "Reset Names" button THEN the names of Context, Strategies, Properties, and Evidence are consecutive and sequential.

Dependencies

No response

Technical Notes

• This is aligned with the behaviour previously available in the Legacy TEA-Platform.
• Names should be aligned to what's specified in: https://github.com/alan-turing-institute/AssurancePlatform/issues/438
• This would require front-end and back-end changes: In the backend, we would offer a new endpoint, and in the frontend, there should be a button that calls it, and re-renders the case (cc. @RichGriff )

Development Tasks

• [x] Implement a new endpoint to trigger identifier update.
• [x] Call this endpoint from a button in the frontend.

Definition of Done

• [ ] The feature fulfills all acceptance criteria.
• [ ] The code is reviewed and meets team coding standards.
• [ ] All unit, integration, and end-to-end tests are passed.
• [ ] The feature meets accessibility standards set for the project.
• [ ] The code passes the CI/CD pipeline quality controls (style and linting).
• [ ] The feature is merged into the main branch.
• [ ] The feature is deployed and functional in the QA environment.
• [ ] The feature was demonstrated to the team and accepted by the product owner.

[cptanalatriste]

The endpoint is complete (see branch attached to issue). @RichGriff will work on the GUI changes

[RichGriff]

Frontend action button toolbar has been updated to include the button for 'Reset Names' - this call the endpoint and reload the assurance case with a page reload.

@cptanalatriste PR ready

[RichGriff]

In staging - @chrisdburr please review

[chrisdburr]

Thanks, @RichGriff .

One immediate change is the text for the tooltip that appears on hover. Please can we change the text from 'Reset Names' to 'Reset Identifiers'.

And can we have a modal/alert that pops up saying the following:

Are you sure? Updating the identifiers will systematically reset all of the unique labels that are displayed for each of the elements (e.g. P1, E1), so that they are continuous. This cannot be undone.

No, keep current identifiers. Yes, reset all identifiers.

[chrisdburr]

@cptanalatriste, please could you add information about what is actually happening when a user clicks this button so I can review thoroughly.

[RichGriff]

@chrisdburr - The frontend change is now in staging

[chrisdburr]

Thanks, @RichGriff. I can confirm that the button label and modal text is correct. However, I'm still not clear on what is happening when this action is actually triggered.

For instance, here is a new case that I created from scratch. Each element is numbered (description not identifier) according to the order in which I created them. However, for some reason the property claims are not numbered incrementally in the identifiers.

I then modify the case by adding some new elements, deleting others, and moving some around. This updates the identifiers for the property claims but not the evidence:

Finally, I trigger the renaming of the identifiers, which returns this:

This seems to take care of the duplicate identifiers, and it appears as though the numbering is now based on the order in which the elements are created. @cptanalatriste please can you explain if this is the expected behaviour?

My preference would be for the identifiers to be continuous from left-to-right when the user tiggers a refresh. So, the following:

• All strategy claims to be continuous
• All first-level property claims to be continuous
  • Where some property claims and strategy claims share the same level (e.g. children of G1), strategy claims should be presented before the property claims (e.g. S1, S2, S3, P1, P2)
• All _n_order property claims to be continuous, but related to their parents (i.e. P1.1, P1.2 if and only if their parent is P1 / P2.1 is skipped if there is no P2)).
• All evidence claims to be continuous, regardless of their parents

[cptanalatriste]

@chrisdburr I think this is aligned with the implementation currently in staging: Top-level property claims are sorted by insertion order (i.e ,the one created first will be P1, the one created last will be P6).

Sadly, the backend is unaware of how/where the case elements are placed in the screen. Given that we are triggering a page reload on identifier update, as a first approximation I would propose a brand-new ordering of case elements after refresh (i.e. some elements might be placed in new positions, but respecting the sequencing logic you mentioned before). Although I would expect this change to take 2-3 days of work, given the new case traversal logic needed.

Also, just to understand the new rules better, can you include the expected Identifiers for the last screenshot you included?

[cptanalatriste]

@chrisdburr after our discussions, I made an update to the "Update Identifiers" algorithms (see PR https://github.com/alan-turing-institute/AssurancePlatform/pull/540 ): It is now "parent aware". With the new version, a case with this configuration (notice the "order" in description if you want to replicate this):

Have the following configuration after update:

These changes are already in staging. Please give it a shot, and let me know if there's another "blind spot" it is urgent to address.

[chrisdburr]

This is looking good, @cptanalatriste.

I haven't been able to break it yet, which is promising. So, I'd be happy to merge this, because if there are any further issues we can just log the individual bugs.

Well done!