"Lazy Circ" automatic barcode prefixes

[Thomas Berezansky]

Add support for a list of prefixes to try when barcodes are entered.

The idea is when a barcode has a library prefix, padding, and "significant digits"

12345000067890 as an example with 12345 being the prefix

You can enter just the 67890 and have the rest built for you.

Adds an org unit setting for prefix/length/padding.

If length isn't specified it adds the prefix regardless as a possibility.
If padding isn't specified it uses 0.

If more than one patron (by DB id) is found it shows buttons for each patron for the circ staff to select from.

Signed-off-by: Thomas Berezansky <email address hidden>

For those who want to use git to pull my git branch:

To add my remote using id "tsbere" (only needs to be done once):

git remote add tsbere git://git.mvlcstaff.org/tsbere/ILS

If you don't use tsbere as the identifier here all of the below commands referring to tsbere will need to be adjusted.

Don't forget to fetch/update the remote:

git fetch tsbere
OR
git fetch --all

This branch will be tsbere/lazy_circ

To check out the branch:

git checkout -b tsbere_lazy_circ tsbere/lazy_circ

To merge into your current branch (change branches first!):

git merge tsbere/lazy_circ

To merge changes you made to your checked out version into the current branch (change branches first!):

git merge tsbere_lazy_circ

[Thomas Berezansky (tsbere)]

Updated to use type of array for org unit setting instead of a pure string.

[Thomas Berezansky (tsbere)]

Probably should have double checked the settings editor view compared to the db view when doing the array type change. Updated the help text to indicate how you actually enter them.

[Thomas Berezansky (tsbere)]

Ok, based on input I have re-done this as a new config table and for more than just users on the patron by barcode lookup screen.

New git branch is lazy_circ2.

Git commit message:

Lazy Circ, Try 2

Database tables/access functions for prefix/suffix info
    Table: config.barcode_completion
    Function: evergreen.get_barcodes
        Takes org unit, context, and input barcode
        Context is a string and can contain:
            asset - asset.copy barcodes
            serial - serial.unit barcodes
            actor - actor.usr (via actor.card) barcodes
            booking - booking.resource barcodes
        Special case: asset and serial both in context
            Returns non-serial asset entries as asset
            Returns serial entries as serial
    Type for function return: evergreen.barcode_set
    With editing interface: Admin->Local Admin->Barcode Completion
    OpenSRF Call: open-ils.actor.get_barcodes
        Basically a passthrough to the database function
Add get_barcode to menu.js and to xulG in a number of places
    Takes a window handle, a context, and an input barcode
    Passes the current OU, the context, and the input barcode to the db
    If multiple results come back it pops up a dialog
    Returns boolean false on no results or dialog cancel
    Returns an object with type, id, barcode on success
Add option for looking up actors at checkout
    Org unit setting: Load patron from Checkout. Default: Don't.
Add calls to get_barcode:
    Lookup Patron By Barcode (actor only)
    Opac's Staff Client Place Hold (actor only)
    Checkout (asset only by default, with actor if above option set)
    Checkin (asset only)
    Item Status (asset only)

Signed-off-by: Thomas Berezansky <email address hidden>

[Mike Rylander (mrylander)]

That's looking great to me. More reviewers needed (focusing on the SC bits) but I have just a couple comments currently:

Minor nits:
 * Space in the JS is used ... sparingly (though, that seems to be the style of the surrounding code ...)
 * Some debugging code (or similar) is hanging about (spurious data.list.au[0].ws_ou() in get_barcode)

Non-minor nit:
 * Security -- specifically, there are no permission or session checks applied, but authoritative, identifying (or, at least, more complete) information is returned

At the very least, we need to check for a valid session, probably for (at a minimum) STAFF_LOGIN, and I'd lobby strongly for VIEW_USER if context contains 'actor' (and analogs for other contexts). This will change the underlying call, but since all callers go through the get_barcode() JS function, which can be in charge of gathering up the session auth token.

[Thomas Berezansky (tsbere)]

Updated lazy_circ2 branch (git://git.mvlcstaff.org/tsbere/ILS repo) with what I hope is enough security changes and such.

[Mike Rylander (mrylander)]

Wheee ... it's in there. Committed to trunk/master as http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=29a874a1f9c99d2eb69b048631d4e5b0dc51a813

[Dan Wells (dbw2)]

Hello guys,

Just looked over this commit, and while I think it is a neat idea with generally great execution, I think the current implementation is too heavy handed. Actions like checkout and checkin happen many, many times a day, and the addition of a multi-stage lookup process (including network and db activity) to every single one, which 99.99% of time will not be needed, seems likely to be a wasteful use of resources. It also seems to me that a feature like this should only run as a fallback mechanism when the normal process fails, and if that isn't feasible for some reason, that there should be some simple way to disable this feature.

Maybe I am missing something?

Thanks,
Dan

[Thomas Berezansky (tsbere)]

It would be fairly easy to add a setting, either org unit based or workstation based, to not attempt it on checkin/checkout. I just don't know if it should be at the org unit, workstation, both, or something else. And if it should be set per interface or global. Do you have any preferences for that?

For users by barcode it replaces a previous one network call with another one network call, and thus I feel is much less heavy handed, and has no need of a setting to turn it off.

As for "only using it as a fallback", the problem there is that if you have something that matches an exact lookup *and* an auto-completed lookup the staff member may never realize that they got the exact match when they were using the partial and thus wanted the auto-completed version. The code as it stands will detect this and prompt for which they wanted. Because of that possibility I feel that it either has to be checked all the time or none of the time.

It may be possible to further reduce the amount of work done by the checkin/checkout/item status interfaces after the barcode should already be valid, though. I have not looked into that at this time.

[Dan Scott (denials)]

It would be awesome in cases like this to be able to automate a run of
1000 circ transactions in a reasonably loaded system before and after
the patch to ensure that there was no significant performance hit.