available copies in web staff client not same as xul

Bug #1744091 reported by Rogan Hamby
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Medium
Unassigned

Bug Description

This sounds familiar to me but I'm not seeing it elsewhere in bugs so hopefully it's not a dupe of an existing ...

In the xul client catalog search we have the following behavior,

search for 'patterson two heart' on initial login on xul client:

Two from the heart
Patterson, James, 1947-
Book Book (2017.)
Call number: F Patterson James
50 of 74 copies available at foo_consortium.
4 of 9 copies available at foo_system.
0 of 2 copies available at foo_branch.

change search scope from the default after login to consortium:

Two from the heart
Patterson, James, 1947-
Book Book (2017.)
Call number: F Patterson James
50 of 74 copies available at foo_consortium.
0 of 1 copy available at foo_branch.

So it continues to show branch copies for the logged in library even when scoped to consortium.

In the web based staff client we get:

Two from the heart
Patterson, James, 1947-
Book Book (2017.)
Call number: F Patterson James
50 of 74 copies available at foo_consortium.
4 of 9 copies available at foo_system.
0 of 2 copies available at foo_branch.

upon changing scope to consortium:

Two from the heart
Patterson, James, 1947-
Book Book (2017.)
Call number: F Patterson James
50 of 74 copies available at foo_consortium.

So, it no longer continues to show registered copies regardless of scoping. Since we've generally tried to make make patron and staff identical this may not be considered a bug but it is a chance in xul -> webby behavior that has confused some staff who expected it to still function this way.

Revision history for this message
Evergreen Bug Maintenance (bugmaster) wrote :

It took me a few minutes to replicate the XUL client behavior, so I'll add a few data points.

In the xul client, an org unit needed to be selected as the workstation preferred library to display it in the availability counts for searches that were outside that scope. It looks like it displays no matter what the scope of the search.

In the web client, if you set an org unit as the workstation preferred library, it does not display regardless of the scope.

tags: added: webstaffclient
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Evergreen Bug Maintenance (bugmaster) wrote :

Adding a few more notes:

- This problem appears to have started in 3.0. I just checked a 2.12 system, and the preferred library information is displaying as expected.
- This bug appears in two places: in the record's availability counts, as Rogan described, but also in the search results page counts, which should also show the preferred library counts.
- This bug occurs in the public catalog, the web staff client, and the 3.0 xul staff client. In the public catalog, the preferred library is based on the user's preferred search library. In the client, it should be based on the workstation preferred library, which oftentimes is different from the ou that is the workstation default search library.
- The record's copy table continues to display the preferred library's holdings ahead of holdings for other libraries, as expected. The bug only seems to affect availability counts.

I verified the 3.0 behavior on a recent master system as well as one that was a few weeks old just to rule out that other recently-merged code that affected availability counts display didn't cause the problem

Revision history for this message
Kathy Lussier (klussier) wrote :

Adding a note that the above two comments were made by me. I forgot to log out and log back in as myself after doing the monthly release churn.

tags: removed: webstaffclient
tags: added: webstaffclient
Revision history for this message
Kathy Lussier (klussier) wrote :

I think this might be a duplicate of bug 1756912. I can't immediately test the behavior to see if it has been fixed, so I'll hold off on marking it as a duplicate.

tags: added: opac search
Revision history for this message
Andrea Neiman (aneiman) wrote :

I can't replicate the reported behavior in a 3.1.8 test system so I think Kathy is correct that this was a duplicate of bug 1756912. Marking as such.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.