UIOR-1499 Refresh order lines after order mutate actions

[usavkov-epam]

Purpose

https://folio-org.atlassian.net/browse/UIOR-1499

When duplicating an order without reloading the page, PO line in the duplicated order is not linked to the original instance and a new instance will be created.

After an order is opened, its state changes and the data is reloaded, but the PO Lines data is not. As a result, when the duplicate action is performed, the request contains stale PO Lines data that does not include the updated fields after the order was opened. Consequently, in the new order—specifically in its lines—there will be no linkage to the created instance and holdings.

Screenshots

Screen.Recording.2026-01-22.at.18.16.52.mov

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

• I've added appropriate record to the CHANGELOG.md
• Does this PR meet or exceed the expected quality standards?
  • Code coverage on new code is 80% or greater
  • Duplications on new code is 3% or less
  • There are no major code smells or security issues
• Does this introduce breaking changes?
  • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
  • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

• What other modules will these changes impact?
• Do JIRAs exist to update the impacted modules?
  • If not, please create them
  • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
  • Do they have all they appropriate links to blocked/related issues?
• Are the JIRAs under active development?
  • If not, contact the project's PO and make sure they're aware of the urgency.
• Do PRs exist for these changes?
  • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

[github-actions]

Jest Unit Test Results

  1 files  ±0  296 suites  ±0   7m 29s ⏱️ +14s
973 tests ±0  973 ✅ ±0  0 💤 ±0  0 ❌ ±0 
981 runs  ±0  981 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 5b8e609. ± Comparison against base commit 3484f1b.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[zburke]

There is zero explanation of how this change resolves the bug. The problem described in the ticket is that the POST request has an incorrect attribute and yet no attributes are being changed here. The CHANGELOG entry describes refreshing data after a mutation, which does not make sense given the reported problem is that the mutation contains incorrect values.

Maybe all the "refetch" changes here are correct, but I can't assess that because you haven't explained what the actual bug is, nor how this code addresses it.