[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: |
|
| 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:
Expected Results: Actual Results: 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/ 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 ] |
|
The cause of the issue is almost the same as in
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. |
| 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. |
| Comment by Cate Boerema (Inactive) [ 26/Nov/20 ] |
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 ] |
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! |