Bug 6357 - Items (un)availability not displayed correctly (OPAC)
Summary: Items (un)availability not displayed correctly (OPAC)
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) minor (vote)
Assignee: Janusz Kaczmarek
QA Contact: Bugs List
Depends on:
Blocks: 5917
  Show dependency treegraph
Reported: 2011-05-17 19:32 UTC by Janusz Kaczmarek
Modified: 2012-10-25 23:09 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:

A screenshot illustrating the problem (13.08 KB, image/png)
2011-05-17 19:32 UTC, Janusz Kaczmarek
Proposed patch (845 bytes, patch)
2011-05-17 19:36 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Proposed patch (with header) (1.16 KB, patch)
2011-05-25 14:35 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Signed-off patch (1.27 KB, patch)
2011-05-27 14:02 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Janusz Kaczmarek 2011-05-17 19:32:34 UTC
Created attachment 4157 [details]
A screenshot illustrating the problem

With the new templates, in results' view in OPAC (having OPACXSLTResultsDisplay set to 'normally') the (un)availability of items is not displayed correctly: if there are no items available, Koha still displays "Availability: Copies available: " (cf. screenshot), whereas it should be "Availability: No items available:" etc.

Apparently the dereference of SEARCH_RESULT.available_items_loop in opac-results.tt is not interpreted correctly (available_items_loop list is empty but [% IF ( SEARCH_RESULT.available_items_loop ) %] is interpreted as true. 

A very simple patch follows.
Comment 1 Janusz Kaczmarek 2011-05-17 19:36:18 UTC Comment hidden (obsolete)
Comment 2 Owen Leonard 2011-05-25 13:16:41 UTC
This patch didn't apply for me ("Patch format detection failed"). I see that the fix is a very simple change. Can you explain how it works?
Comment 3 Janusz Kaczmarek 2011-05-25 14:35:29 UTC Comment hidden (obsolete)
Comment 4 Janusz Kaczmarek 2011-05-25 15:01:15 UTC
I have just uploaded this patch with the header (sorry for cutting it off)--it should apply smoothly now. 

There are apparently some problems with variable scoping / dereferencing in the SEARCH_RESULT.available_items_loop construct.  

Previous (i.e. 3.2) the behaviour was: if there are no items attached at all (just the biblio record) or no item is available (e.g. all items checked out) then "No items available:" message is displayed bellow the title etc. on the collective search results list.  As I look at the new template, now it should be the same.  

BUT is not.  Even if there no items in available_items_loop, the result of the test [% IF ( SEARCH_RESULT.available_items_loop ) %] is positive (I do not know why) and you get "Copies available:" message.

To see this try with records with no items attached both in Koha 3.2 and in 3.4.

So, what the patch does is: it checks explicitly if the first element of the array available_items_loop exist (instead of checking if available_items_loop is not empty).  It is less elegant, but it means the same and it does work as expected.
Comment 5 Owen Leonard 2011-05-27 14:02:14 UTC
Created attachment 4278 [details] [review]
Signed-off patch
Comment 6 Chris Cormack 2011-06-10 03:48:10 UTC
TT bug
Comment 7 Magnus Enger 2011-07-16 09:29:42 UTC
With OPACXSLTResultsDisplay set to 'normally', the OPAC search results correctly displays "No items available: Checked out (1)".