This bug was reported by a colleague (Chalmers) and is currently affecting at least one real patron.
I reproduced it with test user 97362792-3403-41f6-801d-1792082575fa in Chalmers FOLIO environment.
Steps to reproduce:
- Create a user with barcode "89101112"
- Create an request on item A for this user
- In the user record, verify that the user has 1 open request.
- Click on 1 open request to look at this open request for item A in the Requests app.
- Go back to the user record and change the user's barcode to "89101113". Save changes.
- In the user record, verify that the user still has 1 open request.
- Again, click on 1 open request to look at this open request in the Requests app.
Information about the user's open request for item A is displayed.
No open requests are found for the user.
However, I can find the request by replacing the user's current barcode in the search field with the barcode she had when making the request. Changing the user's barcode back to the one she had when she made the request also does the trick - but that's really not something you want to do when it comes to a real patron who lost their library card and got a new one...
Additional info from Cate:
- Let's solve this the same way we solved
UIIN-821(link filter should be by UUID, not barcode)
Additional info from Chalmers:
So, the problem seems to be something like this:
- The request FOLIO uses to fetch a user's requests in the Requests app filters results by the patron barcode (why not the UUID?):
- When I change the user barcode after making the request, there is a disconnect between the new user barcode used by the filter *and *the old user barcode still associated with the request. The new current user barcode thus returns no open requests.
Interestingly, requests-storage stores the user barcode from when the request was created. Compare the user object in these two requests made after I changed the barcode: