[UICHKOUT-410] Server errors when trying to check out items that have been requested Created: 27/Mar/18  Updated: 11/Sep/18  Resolved: 12/Apr/18

Status: Closed
Project: ui-checkout
Components: None
Affects versions: None
Fix versions: 1.2.0

Type: Bug Priority: P3
Reporter: Ann-Marie Breaux (Inactive) Assignee: Michal Kuklis
Resolution: Done Votes: 0
Labels: demo35, sprint35
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File Capture.PNG     JPEG File CheckoutFailErrorMessageOK.JPG     File RequestsCheckoutsErrorMsg.mp4    
Sprint:

 Description   

Overview: Getting ugly error messages when trying to check out something that has been held, recalled, or paged.

Steps to Reproduce:

  1. Log into FOLIO-snapshot-stable as diku_admin
  2. Find a user to check something out to, and copy barcode(s) from the requests list.
  3. Click checkout
  4. Enter the user
  5. Enter one of the held, recalled, or paged items

Expected Results: When finalizing the checkout, FOLIO should display a message reading, "Item is not available for checkout" just as it does when you try to check an item out that has the status "Checked out". See attached screenshot.

Actual Results: Server message, which showed that the checkout could not be completed, but was not the expected UI.

Additional Information: See attached video.



 Comments   
Comment by Cate Boerema (Inactive) [ 28/Mar/18 ]

Hi Ann-Marie Breaux. Unfortunately, the screencast you attached has audio but the visual is just green. Could you please redo or add a screenshot of the error you are seeing?

Does this only happen when you try to check out an item that has been requested or does it apply to any item that is already checked out?

Comment by Ann-Marie Breaux (Inactive) [ 28/Mar/18 ]

Hi Cate Boerema I checked the video and it's showing fine on my laptop. I'll e-mail a copy to you, and see if that helps. I didn't check on whether it applies to all items that are checked out. Will try that now and add another comment.

Comment by Ann-Marie Breaux (Inactive) [ 28/Mar/18 ]

I tried it with 2 checked out (but not requested) books. Both had correct error messages. Screenshot of one attached. Thus, it seems to be limited to requested items that you try to check out.

Comment by Cate Boerema (Inactive) [ 28/Mar/18 ]

Oh! Apparently the videos only don't work in Firefox (they work for me in Chrome). Which software did you use?

Comment by Ann-Marie Breaux (Inactive) [ 28/Mar/18 ]

SnagIt, and I'm using Chrome for my browser.

Comment by Cate Boerema (Inactive) [ 28/Mar/18 ]

I'm just going to assign this to Tania Fersenheim to start, as I'm not sure if we've ever specified the text of the user-friendly messages we want to display in this case. Tania, can you please add the desired text to the expected behavior and then mark it unassigned and put it in the sprint?

Thanka!

Comment by Ann-Marie Breaux (Inactive) [ 28/Mar/18 ]

Even if it's just the red error message that's in the screenshot, that's definitely better than the server message. Not sure it needs anything fancier than that, but that's up to Tania.

Comment by Cate Boerema (Inactive) [ 28/Mar/18 ]

Sorry - hadn't noticed the screenshot before. I agree, that's probably the text we want to use. Tania Fersenheim, I'll save you the bother and just put this unassigned and into the sprint. Thanks!

Comment by Tania Fersenheim [ 28/Mar/18 ]

Ann-Marie Breaux - Until we specify the modals or messages that should appear, we're just seeing the information that the app is returning. The text and/or modal will be different based on different situations. Can you detail for me each of the item statuses and request statuses that were involved in the checkout attempts you made in your screencast? Thanks!

Comment by Ann-Marie Breaux (Inactive) [ 28/Mar/18 ]

Hi Tania Fersenheim - would you just like to use the general "not available for checkout" message like Cate Boerema suggested in a comment above? Or do you definitely want custom messages for every different situation?

Comment by Tania Fersenheim [ 28/Mar/18 ]

Hi Ann-Marie Breaux - The SIG feels it is important (and I agree) that the staff operator be presented with information that helps them understand the situation. Something could be not available for checkout due to being In Transit (for various reasons), not at home, awaiting pickup for another patron, checked out to another patron, etc. The modal or message in each situation will need to contain slightly different information. In some (but not all) of these situations the staff person should be presented with the opportunity to proceed with the checkout if they are authorized to do so, and there will need to be stories written for how the app handles each of the situations. E.g. if the item is checked out to a different patron and the staff person is authorized to proceed anyway, an implicit checkin from the previous user should occur and be recorded as such, rather than recorded as a straight up check in.

Comment by Ann-Marie Breaux (Inactive) [ 29/Mar/18 ]

Hi Tania Fersenheim - here's the scenarios - I think it will also be helpful to look at the video attached to this ticket.

User who was checking out the books: Cathy Gulgowski, Barcode 955597434195045, Patron Group: Staff

Held item: 326547658598 Interesting Times, Item status: Checked out-held
Recalled item: 697685458679 Nod, Item status: Checked out-recalled
Paged item: 5860825104574 14 Cows for America, Item status: Checked out (no indication of paged in the item status, but showing as paged in the requests list)

Comment by Cate Boerema (Inactive) [ 29/Mar/18 ]

The modal or message in each situation will need to contain slightly different information...

This makes sense, Tania Fersenheim. In the near term, though, it would be good to just make a simple fix so things don't appear broken. Would you be okay with our just displaying the basic, user-friendly validation message until those other stories are written and implemented? See the attached screenshot for the kind of message we could easily display.

Comment by Michal Kuklis [ 04/Apr/18 ]

Ann-Marie Breaux thank for for attaching the screencast for this. It's super helpful!

Comment by Ann-Marie Breaux (Inactive) [ 04/Apr/18 ]

Michal Kuklis Glad it's helpful! Much easier for me to record what's happening than to take a bunch of screenshots and write up the problem.

Comment by Michal Kuklis [ 04/Apr/18 ]

Ann-Marie Breaux I added an extra check for requested items. The red error message: "Item is not available for checkout" should show up when you try to check out one of them. This should be available in folio-testing soon.

Comment by Theodor Tolstoy (One-Group.se) [ 06/Apr/18 ]


Tried three differen types of requests, all rendering the same raw error message pop up

Comment by Michal Kuklis [ 06/Apr/18 ]

Theodor Tolstoy (One-Group.se) what environment did you use for testing this? I just tried folio-testing and folio-snapshot and it does work as expected. Would you mind providing more details:

1. What environment was used for testing
2. What barcode was used during checkout

Thanks!

Comment by Theodor Tolstoy (One-Group.se) [ 06/Apr/18 ]

Michal Kuklis
1. snapshot-stable
2. Username: quinn
Item barcode: 697685458679

Although: Item barcode 1522813059329 actually works. I went trhrough at least four this morning, but apparently that was not enough to see a working one.

Comment by Michal Kuklis [ 06/Apr/18 ]

Thank you Theodor Tolstoy (One-Group.se). It looks like this fix is not in http://folio-snapshot-stable.aws.indexdata.com yet. I'm not sure when folio-snapshot-stable was built last time. It looks like the fix is in both http://folio-snapshot.aws.indexdata.com and http://folio-testing.aws.indexdata.com

Comment by Tania Fersenheim [ 10/Apr/18 ]

Cate Boerema et al,

Since the reason the item is not available for checkout is not that it has been requested, but instead is due to it being checked out to a different patron, it should be handled the same as any other checked out item that you attempt to check out to someone else.

It seems to be the statuses "Checked out - recalled" and "Checkedout -held" that make it behave differently than it does for items with the status "Checkedout". The existence of a request isn't truly relevant to what message the staff person should see during the checkout attempt. It's the existence of an active loan that is relevant.

The Loans SMEs may have additional/different ideas of what they want, but in the absence of input from them, I would say that it should be handled the same as any other checked out item that you attempt to check out to someone else.

Comment by Cate Boerema (Inactive) [ 12/Apr/18 ]

Okay, so it sounds like we are all on the same page, Tania Fersenheim and that what was implemented will work for you. Thanks!

Generated at Thu Feb 08 23:11:19 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.