Web Client: Item Status List View missing column options

Adding a link to the related bug 1583729. When adding these columns to the web client, it might be nice to see the age protection field included as well.

From a cursory inspection, these look like the only columns that may give trouble when trying to implement them, due to not being included in the fleshed item:

-Checkin Date
-Checkin Scan Date
-Checkin Workstation
-Checkout Date
-Checkout Workstation
-Checkout or Renew Library
-Circ or Renewal Workstation
-Circulation ID
-Classification
-Document ID
-Edition
-Fines Stopped
-Fines Stopped Time
-Holds Count
-Part
-Remaining Renewals
-Service
-TCN(there are two TCN columns in the XUL xlient, one returns null consistently, while the other returns the actual TCN. This is the null one)
-Transaction Complete

The column choices not present in this list should be simple, really just a matter of adding lines in the tt2 to grab them. The Author field returns in all lowercase, it might be worth having a "capitalize" class applying text-transform: capitalize for anything like this.

Regarding the lower case author, bib fields (title, author, etc.) will migrate to the code in progress with bug #1251394 over time. Some shortcuts were taken in the web staff code (using the reporter data) with this assumption in mind. I'd suggest not worrying about that for the time being, or at least no until we absolutely have to.

Regarding the rest, here's just enough info to create some confusion...

Beware some of this data, particularly the checkout/transaction data, will not be accessible via simple pcrud flesh query, the kind used by the itemSvc service in the item status app. (See the service.flesh object). Since a copy can be checked out many times, we have to decide which transaction's data will be displayed (before the data is fetched).

The XUL item status UI likely uses one of the open-ils.circ.copy_details.retrieve API calls, that handles all of this logic on the server. One option would be to grab supplementary data for each copy via this API call.

Or we could implement the similar logic via pcrud from the client. We do this to some degree already in ViewCtrl, e.g. loadCurrentCirc().

The Perl API is stable and well understood. Pcrud is generally faster and gives us more control in the client over what data we want to retrieve.

I'm not leaning in any direction at this point, just wanted to pass this on before we go down any dark alleys.

After some experimentation(and more ongoing poking around), my thoughts would be that going the pcrud route would be ideal IF we can get the circ information once through itemSvc, and integrate it into our copy, rather than having it in both the list and detail controllers. It would be more complicated than a quick port of the existing usage in the detail controller, but it would also likely have the least calls happening. I've been able to get close to this, but each attempt runs just shy of results - usually having to do with itemSvc.copy not liking the added circ information, if it even finds it at all.

The main reason I think Pcrud is the way to go here is because of the measure of control we're getting with Pcrud. Using the Perl API comes with a lot of benefits here, but the sheer amount of information we return seems like it might be wasteful, resource-wise. It will also need a bit of extra work to get required information from the bib record(that, or I haven't been fleshing things as well as I should be able to, both are possible). That's not to say that using Pcrud for the circ information won't be tricky.

The reason for wanting it in itemSvc, besides just avoiding unnecessary code duplication, is that we could theoretically get the information for each item all at once - In the details view, loadCurrentCirc has the luxury of working with a single item. In the list view, we're working with multiple items. If the Pcrud allows getting everything at once, we'll be looking at less risk of instability/slowdown on very large item lists(not 100% sure this would happen, but it seems like something that might).

I'll continue poking around, and try to find a way to contradict myself on this, but I'm also going to leave this up for grabs until I think I've figured out something more substantial.

I've made some headway here, so I'm assigning myself. So far, I've been able to add and populate the circ and circ_summary(accs) columns. However the current state of the code breaks the detail view. Once I have every field, and have cleaned them up(readable dates, for example), I'll have to do a refactor of the detail view in order to take advantage of the new information being brought in.

Prior to this commit, an item in the item status itnerface was just a flattened copy of acp data. I've added ._circ and ._circSummary, both themselves flattened copies of the circ and accs data tied to the copy.

So there are a few of these that I'm not sure on(the XUL client doesn't give me enough, or some things seem sane, but show as empty in the XUL), but here's a list of what I've been able to figure out so far:

1. Edition - this exists in the MVR, but I'm not sure where its parallel is on the record itself
2. Holds Count & Parts - These should be accessible already, as they're in the acp. However I only seem to be returning the first 33 entries of the copy, and I can't seem to specify holds_count and parts.
3. Service - I'm not entirely certain what this one is referring to. no hints in the IDL or in the XUL Client(seems to come back as empty on any item I look at).
4. Transaction Complete - I'm guessing this refers to xact_finish, in the circ class, the transaction finish date/time.
5. Checkout/Renewal Library - I'm guessing this one is also in the circ class, as copy_circ_lib.

Hi Kyle,

I just wanted to mention that in a quick survey among some people here, we didn't see a need to show Edition or Service in the item status screen, and we were generally ambivalent about seeing the Transaction Finished field.

Having said that, the Edition usually refers to the 250 field in the MARC record. We also are uncertain about the intent of the Service field.

So I've made some good headway here, and have a WIP branch at: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1528924-item-status-columns

I'm wondering if I can get another set of eyes on this. Everything seems to be working fine so far except the dates. I can retrieve all the dates from the relevant copy, circ, and accs data as timestamps, however I'm having trouble getting them to format correctly. Dates from the circ and accs data don't seem to appear at all when trying to format them(though their timestamps are in the scope).
Most of the dates from the copy data are fine, with the exception of Status Changed Time, which shows up, but formats incorrectly.

In my modified t_list.tt2, we're looking at Due Date, Checkin Date, Checkin Scan Date, Checkout Date, Fines Stopped Time, Status Changed Time, and Transaction Complete.

I'm going to retract that comment RE: Dates not formatting. I ended up just needing a small change to fix it. Will test this a bit, and add a pullrequest when I'm certain everything works perfectly.

I remembered something from bug 1615845 - the in house use column request being pushed off to this issue. I've updated, and after some testing on my end, pushed up.
Test plan:
1. Ensure you have a copy that has been circulated
2. Go to Circulation -> Item Status
3. Input barcode of copy without any circulations
4. See that the information displays as expected on the grid
5. Input barcode of copy with circulations
6. See that the information displays as expected on the grid
7. Check the details view of both copies
8. See that the information displays as expected

I just made a quick update to this, rebasing it off of the latest code for but 1615845.

This looks good, and I've pulled it into the webstaff branch (so, marking it fix-committed). The one change I made was to use the localizable timestamp format 'short' instead of hard coding 'MM/dd/yy HH:mm a'.

Thanks, Bill and Kyle!

I believe there may be a redundant </eg-grid> at the bottom of t_list.tt2 on line 149.

I'm not sure if it will actually cause problems but it should probably be removed.

Steve

I believe this patch breaks things for non-existent items scanned into the interface:

TypeError: Cannot read property 'id' of undefined
at fetchCirc (app.js:125)

We don't get the normal feedback at this point.

Hi Jason,

I'm setting the bug status back to Fix Committed since the code was indeed committed to master today. I think it might be a good idea to file a new bug about this issue, at which point we can either submit code to fix the bug or revert the commit that was pushed to master.

Since I came across the same problem when testing patches tonight, I filed the new bug at bug 1683575. Thanks Jason!

There was minor thinko in the committed patch here that cause the list view to intermittently retrieve the wrong most-recent-circ. Just noting here that commit 9aa7147f55fb23fe68d4633e23587fa929897de5 addresses that problem, and is currently living in the to-be-merged webstaff serials branch, which will go in for 3.0.