Improve Messages on OPEN_CIRCULATION_EXISTS condition

Bug #921806 reported by edoceo on 2012-01-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

When performing a checkout in the staff-client for a patron the condition may occur where a barcode is scanned twice. The warning message shown is the same for two different conditions:
  * Checkout of items already in open circulation by another patron
  * Repeated checkout of the same item (duplicate scan)

Would like to have two error messages:
  * This item was checked out by another patron on %1$s
  * This copy is already checked out to this patron!

The attached patch for this adds those to messages to and then updates the OPEN_CIRCULATION_EXISTS condition handler in checkout.js to use these messages.

Evergreen 2.1.0 but this patch is from git master from today.
OpenSRF 2.0.1
PostgreSQL 9.1
Gentoo 64bit, kernel 3.0.6, glib 2.28, glibc 2.13

Jason Etheridge (phasefx) wrote :

Please note that there is an existing feature where a checkout of an item to user who already has the item could result in a renewal, so make sure whatever you do plays nicely with that.

edoceo (edoceo) wrote :

The code I've modifed checks that the checkout date & today are the same (based on date only, not time). However in order to work properly it requires that the time on both the database server and work-stations are closely in sync.

edoceo (edoceo) wrote :

Here is a patch against the git from today. (56fa348..3391572 master -> origin/master)

edoceo (edoceo) wrote :

This patch has improved the messages;

Jason Stephenson (jstephenson) wrote :

edoceo, can you put this on a publicly accessible git server as a branch somewhere?

Jason Stephenson

On Mon, Feb 6, 2012 at 2:08 PM, Jason Stephenson
<email address hidden> wrote:
> edoceo, can you put this on a publicly accessible git server as a branch
> somewhere?

Note, we also have such a git server available for all-comers with an SSH key:

edoceo (edoceo) wrote :

These are updated notes from KCLS for checking out this issue, including use-case and testing methods

The action of attempting to check out an item that is already checked out brings up a dialog box
of “Force CKO?”. Add to the dialog box whether or not the item is being checked out to the
same current patron in the same day, or if the current patron is a different patron. A renewal in
the form of checking out the item to its current patron after the original checkout date should still
be allowed.

Use Case:
Staff member is checking out to a patron. An item barcode is scanned twice by mistake. The staff
member needs to know if the alert is about a double scan, if the item is checked out to a different
patron and needs to be checked in first, or if the patron is intending a renewal.

Testing Procedures

Patron A has item 111 checked out.
Patron B has item 222 checked out.
Open Patron A’s record at least one day later.
Within Checkout, scan item 333.
Scan item 333 again. Does alert let you know that it was a double scan issue?
Scan item 111. Does item renew?
Scan item 222. Are you aware that this item is checked out to a different patron?

edoceo (edoceo) wrote :

Here's a link to the branch I made for this.

Jason Etheridge (phasefx) wrote :

Edoceo, this looks good to me (just observed behavior, didn't compare against KCLS' spec). My only suggestions are cosmetic:

1) pick item or copy (we're already inconsistent throughout the software, but hey)
2) put punctuation between the dialog messages

I'll be happy to push if you or someone wants to effect those changes.


-- Jason

edoceo (edoceo) wrote :

Fixing all to "copy" is easy, committed to my git-branch.

The punctuation issue however is a can of worms. Shouldn't the other messages terminate themselves properly? Some text in have a full-stop at the end, others do not. Seems un-good for code to check if previous messages have; and add if necessary. I don't think punctuation handling should be done in this code (it's not like that elsewhere in Evergreen).
I could go through all the messages in adding a terminating full-stop on those that don't have one.

Looking for suggestions on what the right fix is here.

Jason Etheridge (phasefx) wrote :

> The punctuation issue however is a can of worms.  Shouldn't the other messages terminate themselves properly?

Probably. I don't even know if they're all complete sentences, to be honest. :)

> Looking for suggestions on what the right fix is here.

I'm inclined to be programmatic. When you concatenate to msg, could
separate with a slash if msg isn't empty.

-- Jason

edoceo (edoceo) wrote :

I looked around at the properties, trying to discover the ones that could be prefixing the messages I want to add. I would have ended up changing a number of strings - and I didn't know the other consequences of that. I agree the '/' is the proper thing to do. Added ' / ' as a separator. Also made sure the strings I added had proper punctuation. Committed to my git. Thanks!


edoceo (edoceo) on 2012-07-11
tags: added: pullrequest
Changed in evergreen:
importance: Undecided → Wishlist
Changed in evergreen:
status: New → In Progress
assignee: nobody → Jason Stephenson (jstephenson)
Jason Stephenson (jstephenson) wrote :

Pushed to master!

Thanks to Edoceo & KCLS.

Changed in evergreen:
status: In Progress → Won't Fix
status: Won't Fix → In Progress
status: In Progress → Fix Committed
assignee: Jason Stephenson (jstephenson) → nobody
milestone: none → 2.4.0-alpha
Ben Shum (bshum) on 2013-05-19
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers