With this bug fix pushed to Trillium now, does that mean our request to upgrade this to a P2 has been denied? With the release schedule, we’ll be likely looking at another year of time consuming manual file splitting here. A response would be helpful.

Just the other week, we saw a log entry where the entries weren’t in order. It started at number 3. Also, all 6 entries didn’t display in the log. I captured the whole log below. This was for a create profile where we create instances, holdings, and items and then run a modify to remove those marc fields used to create the holdings and items. This is at Five Colleges. The log entry numbers already aren’t in order. When you try to sort, they don’t sort in order.

Support Sig: please review the comment below from and consider how it affects their library and their rationale for classifying this as a P2 instead of a P3.

This is impacting UChicago in the following way, which we believe aligns with a P2 priority and this is currently prioritized as P3. This bug means that we cannot load orders with more than 50 records due to the UI display problems, and we have implemented a workaround of splitting larger files into multiple smaller files for loading. This can have a significant impact. For instance, one day we received ~550 orders from one vendor. In the past we would have loaded the orders as a single file, but with our workaround, staff must split files into separate loads of 50 records. With the example of the 550 record file, it took the staff member most of a day to process and load the orders because it was done as 11 separate files.

Further testing indicates that this behavior is only observed for order imports that set the Purchase Order Status to “Open”. Tests with a profile that set the Purchase Order Status to “Pending” display all of the records in the correct order. Paging also works.