Inconsistency between client and opac availability counts for statuses with is available flag

[Kathy Lussier]

Evergreen version: 3.0+

When the is_available flag was added to Evergreen in 2.11, it allowed materials with an is_available status to be retrieved with a 'limit by available' search, but did not affect the count of available items that displays on the search results page and in the Available Copies section of the bib record. Those availability counts continued to only count items with a status of Reshelving, Available, or Reserves.

As of 3.0, the availability count in the public catalog now counts any copy with a status where the is_available flag is enabled. However, the count that displays in the staff client continues to use the old method.

To test:

1. Enable the is_available flag for the In Process copy status (or another status of your choosing).
2. Add a bib record to the database and then add a copy that is still in the In Process status.
3. Retrieve the record in the staff client. You will see that the search results page and record say that 0 of 1 copies is available, which is consistent with previous behavior.
4. Log out of the client and search for the same record in the public catalog. The search results and record page will say that 1 of 1 copies is available.

The two counts that display in the client and public catalog should be consistent.

[Joan Kranich (jkranich)]

Confirmed in Release 3.0.8.

[a. bellenir (abellenir)]

the database function asset.staff_ou_record_copy_count was using the hardcoded status list of (0,7,12) to count "available" copies instead of obtaining a list of config.copy_status where is_available is true.

here's a branch where the asset.staff_ou_record_copy_count function uses the same logic as asset.opac_ou_record_copy_count: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/abellenir/lp1775216-inconsistent-avail-counts

if this change is acceptable, other database functions that include the hardcoded (0,7,12) list may want to be updated as well:
* asset.staff_lasso_record_copy_count
* asset.staff_ou_metarecord_copy_count
* asset.staff_lasso_metarecord_copy_count

[a. bellenir (abellenir)]

added a pgtap test. feedback on the testing strategy would be appreciated.

additional inconsistency was discovered where the opac counts included copies for deleted call numbers.

branch has been updated to exclude deleted call numbers from the opac counts.

more discussion from IRC here: http://irc.evergreen-ils.org/evergreen/2018-06-08#i_363334

[a. bellenir (abellenir)]

pgtap test fails on concerto data because staff copy counts do not include peer bib copies but opac copy counts do: bug 1587620

[a. bellenir (abellenir)]

updated to include peer records in staff count, per bug 1587620. pgtap now passes.

[Kathy Lussier (klussier)]

I'm testing this branch now, but I first wanted to mention a community practice with upgrade scripts. There's no need to number the upgrade script when you first create the branch since several upgrade scripts are likely to go in before a branch is tested and merged. Instead, we just ask the developer to use XXXX when submitting the code. The core committer who ultimately merges it to master will give it a name.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=3a7677887ff5f4433a474b8690a18d5a0c85a5ea

I don't think there's any need to change it for this branch, but just letting you know for future upgrade scripts.

Thanks!

[Kathy Lussier (klussier)]

It works for me! PgTap tests are passing too. I squashed a couple of commits and merged the code to master, release 3.1, and release 3.0.

Thanks idjit!