Bug 19572 - opac-result item avaibility not the same as opac-detail shows
Summary: opac-result item avaibility not the same as opac-detail shows
Status: RESOLVED DUPLICATE of bug 7611
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-02 20:30 UTC by David Bourgault
Modified: 2019-02-14 14:10 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Bourgault 2017-11-02 20:30:06 UTC
This is an issue two of our clients have encountered : the item avaibility in the result page does not match the one in the detail page.

e.g.: The items have a notforloan value of -2, which is mapped through Authorised_Values to "In Processing" (or equivalent) but on the OPAC result page, it is displayed as "On Order". The detailed page show the correct value.

From my analysis, this is because whereas the intranet results and the opac details use the database to get items statuses, the opac result goes through the XSLT processing, and doesn't have access to the Authorised_Values table. This is worked around by some hardcoded values in the "item namespace" created by XSLT.pm.

It's possible to fix this issue case-by-case for each client, but that's a very ugly solution.

I don't plan to submit a patch to this bug, because I am not sure how to solve the issue.

(If my explanations are unclear please tell me)
Comment 1 Katrin Fischer 2017-11-02 20:45:06 UTC
The result page groups the different values, lost, not-for-loan (negative values = on order, positive = reference). Fixing this to show the value from the authorised values has been discussed on a different bug (can't locate it right now)
Comment 2 Joy Nelson 2019-02-14 14:10:09 UTC

*** This bug has been marked as a duplicate of bug 7611 ***