Include count of in-house uses as a column in item status

[Jane Sandberg]

This would be very helpful for folks who are involved in our weeding efforts. We have many books that are never checked out, but do see a lot of in-house use, and it's hard for our staff to get at these data. Including it as a column in the item status screen would be very helpful for us!

We are on EG 2.9.1.

[Yamil (ysuarez)]

Thanks Jane. We are running a weeding project here, and was planning on submitting this same bug.

[Terran McCanna (tmccanna)]

+1

[Kyle Huckins (khuckins)]

I've been looking into this a little, and from what I can tell, in house uses seem to exist only as a temporary count, never saved, never remembered(from a note in the 2.2 documentation(http://docs.evergreen-ils.org/2.2/_in_house_use_f6.html), which I haven't seen overruled, it seems it doesn't update the total checkout count of an item at all, which points toward this as well). One way to handle this might be to integrate the current form of in-house-use checkouts with actual checkouts, with a new boolean to display whether it was in-house or not. This would require a minor DB change, possibly some edits to the API methods handling checkout to account for the new field, and then integration into the in-house use interfaces.

[Bill Erickson (berick)]

Kyle, see the action.in_house_use table and associated "aihu" class in fm_IDL.xml.

Adding open-ils.pcrud support for accessing in_house_use objects in the IDL is probably a good start. egCore.pcrud can do count(*)-ish calls to get totals.

This will mean an additional API call per copy in the list to get the counts. On that note, perhaps it would make more sense to display this information on the copy detail display, where we have other circ count data, instead of the list?

[Kyle Huckins (khuckins)]

Oh. Oh! I don't know how I missed that. Thanks Bill, with the table name in mind, I'm definitely seeing it get pushed up to the DB when I record, which means pcrud should have access already. So that's a lot less complicated than I thought it would be.

Looking at the Item Status list in both the existing XUL client and the web staff client, it looks like there's less information currently implemented in the web client, which just has barcode, call number, location, and title. the XUL client seems to have anything that would be listed under the detail view, so it might be good to place the information in both interfaces(having it in the list would definitely speed up the process for people weeding), in anticipation for the other bits of info being implemented?

[Bill Erickson (berick)]

Kyle, unlike cstore, pcrud access has to be explicitly granted in the IDL. Here's a branch that adds pcrud access for in-house-use circulations. While I was in there, I did the same for non-cat in-house-use. The latter has no bearing on this bug, but seems likely to come up in the webstaff eventually.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/lp1615845-in-house-use-idl

The XUL client does have a lot more columns in the item status page, but unless I'm missing it, in-house-use counts is not one of them. I'm not necessarily opposed to displaying the data in the list view, just wary of adding additional API calls to arbitrarily-large list interfaces, especially when there is already a detail view set aside for this purpose. It also begs the question, why not display the other circ counts (from the detail view) in the list view, since they would probably be even more useful?

Anyone else care to weigh in?

[Kyle Huckins (khuckins)]

Adding that now that I've seen this issue on the mailing list: https://bugs.launchpad.net/evergreen/+bug/1528924
It might be better to handle the list view column in that issue, if desired, while dealing with the detail view in this one.

[Kyle Huckins (khuckins)]

I've created a branch with a working in-house field in the item status screen: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1615845-in-house-use-item-status

To test:
1. Enter the item status detail view for a specific item.
2. See that the in-house use field exists and displays the correct number.
3. Record any amount of in-house uses to the item through the record in-house use interface
4. Return to the item status detail view for the same item
5. See that it's updated as expected.

[Kyle Huckins (khuckins)]

Also: It might be worthwhile to set up a card for making the item status detail view a bit less messy - at the moment it might trigger OCD in some people with how it's currently laid out.

[Dan Wells (dbw2)]

I really appreciate the beautiful code simplicity of this solution. However, though I have learned a bit to relax my natural parsimoniousness, I think we need to pause here and think about different options.

Here is what I understand this code to do:

1) Gather up all the in-house use rows for a given copy.
2) For every use, check if the user has permission to view circulations at the in-house use lib.
3) Send every allowed in-house use object to the client.
4) Loop over all the objects and count them.
5) Display the count.

This feels like an awful lot of effort for a singular piece of data.

Ignoring the bigger picture, one thing I immediately wonder is whether we need the permission check at all; unlike a real circ, I believe there is no sensitive data in or linked to the in-house use table.

Aside from that, though I think we need to consider shifting to either a dedicated API method or an IDL/DB view solution. A first thought would be either a peer structure to 'circbyyr', or even extending it to include this data.

Thoughts?

[Bill Erickson (berick)]

Dan, your parsimoniousness warms my heart. Going into this, I thought pcrud could do count(*) calls, but I'm not finding any evidence of that now. A dedicated API may be the way.

However, I also agree we could remove the <retrieve/> permission requirement for in-house-use. We are exposing no patron data there and no more staff data (a database ID) than we already expose on bib records, copies, etc. We could also make the pcrud call leaner by using an 'id_list' (return ID's instead of objects) call and making it atomic, to reduce the network I/O.

[Bill Erickson (berick)]

I pushed modified commits back to:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/lp1615845-in-house-use-idl

1. IDL access is now permission-free for retrieve on in-house and non-cat-in-house objects.
2. Item Status UI makes an atomic, id_list call to get the counts. (I squashed this into Kyle's commit).
3. Item Status UI removes the redundant TCN value from the item status columns to make room for the in-house-use counts field, columns rearranged so they all line up once again because it was driving me insane.

[Terran McCanna (tmccanna)]

Looks good!

I have tested this code and consent to signing off on it with my name, Terran McCanna, and my email address, <email address hidden>.

[Dan Wells (dbw2)]

Bill, I wondered the same thing about count() in pcrud. Would be a nice enhancement.

Overall, the updated solution is a much happier medium, and works fine for me also in testing. Pushing to master.

Thanks, all!