UIOR-1325 UIOR-1351 Add submit actions for PO and PO Line forms

[usavkov-epam]

Purpose

https://folio-org.atlassian.net/browse/UIOR-1325
https://folio-org.atlassian.net/browse/UIOR-1351

Enhance the ui-orders module by adding submit functionality for Purchase Order (PO) forms and Purchase Order Line (PO Line) forms. This change aims to improve user workflows and align the module with updated business requirements.

Approach

• Introduced new actions to handle the submission of PO and PO Line forms.
• Updated the form validation logic to ensure data consistency during submission.
• Modified related components to support the new functionality.
• Added unit tests and integration tests to validate the new features and ensure backward compatibility.

Screenshots

Purchase order form (via "New" button)

chrome_tcdl7HLF0z.mp4

Purchase order form (via Inventory instance)

chrome_Zorzk70ZqM.mp4

---

Purchase order line form (via "Add")

chrome_Xu3Bvgo7Gt.mp4

Purchase order line form (via Inventory instance)

chrome_khk9qqOMqv.mp4

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 Statistics

    1 files  ±0  265 suites  ±0   7m 8s ⏱️ +15s
708 tests +6  708 ✔️ +6  0 💤 ±0  0 ❌ ±0 
716 runs  +6  716 ✔️ +6  0 💤 ±0  0 ❌ ±0 

Results for commit d3a561d. ± Comparison against base commit bf8f7c0.

♻️ This comment has been updated with latest results.

[github-actions]

BigTest Unit Test Statistics

0 tests  ±0   0 ✔️ ±0   0s ⏱️ ±0s
0 suites ±0   0 💤 ±0 
0 files   ±0   0 ❌ ±0 

Results for commit d3a561d. ± Comparison against base commit bf8f7c0.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud