[UIREQ-566] Request queue figures are not accurate in Move Request dialog Created: 24/Nov/20  Updated: 18/Mar/21  Resolved: 30/Nov/20

Status: Closed
Project: ui-requests
Components: None
Affects versions: None
Fix versions: 5.0.0

Type: Bug Priority: P2
Reporter: Molly Driscoll Assignee: Sergiy Sergiyenko
Resolution: Done Votes: 0
Labels: support, ui-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft Word Request queue figures are not accurate in Move Request dialog.docx    
Sprint: Core: F - Sprint 102, Core: F - Sprint 103
Story Points: 1
Development Team: Prokopovych
Release: Q3 2020 Bug Fix
Affected Institution:
Chalmers
RCA Group: Data related (ex. Can be detected with large dataset only)

 Description   

Overview: Request app - Number in "Request queue" column when moving a request is not correct When we look at the overview of open requests on items in an instance we can see accurate totals in the request queue. The same is evident when we open each item to see the requests. But when we want to move a request the column with "request queue" shows another number (generally lower, and sometimes 0). Please see attached file for more details and screen shots.

Steps to Reproduce:

  1. Log in to Goldenrod and/or Honeysuckle Bugfest.
  2. Find a single instance record with multiple items (e.g. A Crack in the spine :prehistory and ecology of the Jimi-Yuat Valley, Papua New Guinea)
  3. Ensure that all items are checked out.
  4. Add several recall requests to each item.
  5. Open the Requests app.
  6. Search for the title from step 2.
  7. Open a request for that title.
  8. In the actions menu, select "Move request".
  9. Check the number in the "Request queue" column against the number on the item record.

Expected Results:
The number in the "Request queue" column should match the number in the "Requests" field in the item record.

Actual Results:
The number in the "Request queue" column does not match the number in the "Requests" field in the item record. It is often lower, and many times 0.

Additional Information: Behavior originally reported by Chalmers, but verified in Bugfest environments (both Honeysuckle and Goldenrod). Screenshots of initial report and troubleshooting in attached file.

URL: https://chalmers.folio.ebsco.com/
https://bugfest-honeysuckle.folio.ebsco.com/
https://bugfest-goldenrod.folio.ebsco.com/ (same release as Chalmers)

Interested parties: Maryam Vardeh



 Comments   
Comment by Cate Boerema (Inactive) [ 25/Nov/20 ]

Molly Driscoll, please let me know if you think this requires a honeysuckle bugfix/hotfix.

Comment by Molly Driscoll [ 25/Nov/20 ]

Cate Boerema, I would say yes, if possible. Chalmers submitted this ticket with high importance. While there is a workaround (checking each item record individually to verify request counts), it is tedious and has a significant impact on productivity.

Comment by Cate Boerema (Inactive) [ 25/Nov/20 ]

Sergiy Sergiyenko, I was able to log into Chalmers's environment and I can see the issue there. I will upload a screencast. I'll see if I can repro this in another environment, as well, but hopefully this helps.

Comment by Cate Boerema (Inactive) [ 25/Nov/20 ]

Actually, I just realized I shouldn't attach the screencast here because it has real patron data. I'll send it to you privately

Comment by Sergiy Sergiyenko [ 25/Nov/20 ]

Molly Driscoll, Cate Boerema

The cause of the issue is almost the same as in UIREQ-541 Closed - the limit (10 by default) on display requests for items when using the 'Move requests' dialog.
I suggest increasing it to 1000.

cc Zak Burke

Comment by Cate Boerema (Inactive) [ 26/Nov/20 ]

Thanks Sergiy Sergiyenko. I'm not sure what the "limit" means exactly. If we change it to 1000, will the move requests popup show the correct number so long as none of the items have more than 1,000 open requests on them? If so, I think that would be fine, as request queues don't get that long.

Comment by Sergiy Sergiyenko [ 26/Nov/20 ]

So, we are talking about the total number of requests for ALL items of a particular instance.
And on bugfest-honeysuckle we already have the instances containing more than 100 items (see UIREQ-558 Closed ).
We can assume that all/most of these items may have the request (or requests) for them. Thus, the number 1000 doesn't seem overstated.

Comment by Cate Boerema (Inactive) [ 26/Nov/20 ]

Thanks for clarifying. I agree, then 1000 sounds good (actually, why not make it 5,000 just to be safe)? And, just to be clear, only open requests will count against the limit, right? Because if we are talking about closed requests, they could quickly pile up.

Comment by Sergiy Sergiyenko [ 26/Nov/20 ]

No, no, Cate Boerema, these are only open requests.

It would be nice to hear Zak's opinion on this limitation.
For now, I'll create a PR with a limit of 1000 and wait for Zak Burke's review.

Comment by Cate Boerema (Inactive) [ 26/Nov/20 ]

No, no, Cate Boerema, these are only open requests.

Oh good! Well, Zak Burke is off today and tomorrow. Is there anyone else who could do the code review? Ideally, we'd get this tested in snapshot and BugFest before Monday's go/no go meeting for Honeysuckle.

Comment by Cate Boerema (Inactive) [ 30/Nov/20 ]

Okay, Bohdan Suprun let me know that this was merged last night so I went ahead and tested it in snapshot. I added 15 requests of different types across 4 different items within ABA. From Inventory instance I went to Actions > View requests and reviewed the number of requests showing per item there. I drilled into each item to verify that the number displaying in the popup matched the number on the item record. From the item record, I clicked the link to the Request app to verify that the number showing there matched the count showing on the item record. Then, from one of the requests in the request app, I clicked "move request". I then cross-checked the counts displaying in that popup with the counts displaying in the View requests popup in Inventory. Everything matched up.

Any other testing you think I should do, Sergiy Sergiyenko? How risky do you think it would be to backport this to Honeysuckle at this point? What would need to be re-tested in BugFest?

Normally I'd put this into Awaiting release, but I'm not sure if you had intentionally left it as "In code review". Thoughts?

Comment by Cate Boerema (Inactive) [ 30/Nov/20 ]

Oh, I see this is now In review. Given that, I am going to mark it Awaiting release.

Comment by Sergiy Sergiyenko [ 30/Nov/20 ]

Cate Boerema

How risky do you think it would be to backport this to Honeysuckle at this point? What would need to be re-tested in BugFest?

From my point of view, this is not risky, since the change of the limit will display only in the Move request dialog and will not affect any other functionality.

Comment by Cate Boerema (Inactive) [ 30/Nov/20 ]

Okay, thanks Sergiy Sergiyenko! Zak Burke, can you please create a release for this when you start working today? I am still hopeful that we can get this into the first Honeysuckle release (go/no go meeting is today)

Comment by Zak Burke [ 30/Nov/20 ]

version 4.0.5, including this ticket, has been published.

Comment by Oleksii Petrenko [ 30/Nov/20 ]

Molly Driscoll Deployed to bugfest, please verify

Comment by Cate Boerema (Inactive) [ 30/Nov/20 ]

Sergiy Sergiyenko, this works in BugFest! Thanks for getting this fixed so quickly! Thanks for the speedy release, as well, Zak Burke!

Comment by Molly Driscoll [ 30/Nov/20 ]

Sergiy Sergiyenko, seconded! This worked for me in Bugfest as well. I really appreciate the quick response to this bug on all fronts and will relay this progress to Chalmers!

Generated at Thu Feb 08 22:21:20 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.