Clones Orchid CSP 6 on UIIN-2565

Overview:
Sorting on the item table is not working when there is more than 1 page of items (200+ items)
(formerly MODINV-867)

Steps to Reproduce:

1. Create field mapping profile and action profile for creating items

   • Material type: 945$b

   • Copy number: 945$c

   • Permanent loan type: pick a value

   • Status: pick a value

2. Create field mapping profile and action profile for creating holdings

   • Permanent location: 945$a

3. Create job profile

   • Action: Default create instance and SRS MARC

   • Action: Create holdings

   • Action: Create items

4. Import the attached file, which will create 1 instance, 1 holdings, and 351 items

5. Use that item list to check sorting

Expected Results: Items sort from 1-200 on first page, then 201-351, for any column header that is picked (using the copy number column is easiest)

Actual Results: Items sort by column header, but only appear to sort within the page of items, not across pages

Additional Information:
Job profile on Orchid Bugfest: https://bugfest-orchid.int.aws.folio.org/settings/data-import/job-profiles/view/6f368782-bc22-49a8-bbad-484815e36cf5?sort=name BUT cannot import the attached file to Orchid BF and create 351 items, since Orchid does not support multiples...

Interested parties:

ORCHID Critical service patch details

1. Describe issue impact on business: Fixes the second part of a regression that was introduced in an earlier Orchid CSP (by a different dev team) where sorting in the item record table under the holdings, in the instance detail record, stopped working. When there are large numbers of item records associated with a holdings, the lack of sorting makes it difficult for production libraries to identify specific item records that need attention. The first fix on UIIN-2528, fixed sorting within a page of items (200 items). This Jira fixes the sorting across all pages of items under a holdings

2. What institutions are affected? (field “Affected Institutions” in Jira to be populated) - All that have large numbers of item records associated with specific items

3. What is the workaround if exists? No user workaround, other than paging through many, many pages of item records, which is very time-consuming

4. What areas will be impacted by fix (i.e. what areas need to be retested) Inventory Smoke and Critical Path automated tests, plus the specific manual test associated with this Jira

5. Brief explanation of technical implementation and the level of effort (in workdays) and technical risk (low/medium/high).

   • Work is complete and the level of effort was minimal, though disruptive to have to attend to this unexpected regression. 

   • Use sorted records array instead of initial items prop

   • Risk to backport: Minimal

6. Brief explanation of testing required and level of effort (in workdays). Provide test plan agreed with by QA Manager and PO. Automated and manual test cases already exist and level of effort is 1 hour

7. What is the roll back plan in case the fix does not work? Revert to previous version