Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs
Summary: Make display of shelving location and call number in XSLT results controlled ...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Elliott Davis
QA Contact: Paul Poulain
URL:
Keywords:
Depends on:
Blocks: 9995
  Show dependency treegraph
 
Reported: 2010-08-02 15:46 UTC by Jane Wagner
Modified: 2018-08-23 11:01 UTC (History)
13 users (show)

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


Attachments
Patch to add/remove shelving location in xslt opac-search (11.56 KB, patch)
2011-06-26 21:08 UTC, Elliott Davis
Details | Diff | Splinter Review
errors (73.83 KB, image/png)
2011-06-29 19:36 UTC, Nicole C. Engard
Details
patch to add call numbers and shelving location (13.51 KB, patch)
2011-06-30 21:42 UTC, Elliott Davis
Details | Diff | Splinter Review
no call numbers on results (43.38 KB, image/png)
2011-07-01 00:43 UTC, Nicole C. Engard
Details
the second item does have a call number (36.61 KB, image/png)
2011-07-01 00:44 UTC, Nicole C. Engard
Details
patch to add call numbers and shelving location (120.07 KB, patch)
2011-07-01 18:49 UTC, Elliott Davis
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs - Part 1 (11.69 KB, patch)
2012-04-25 14:06 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (118.27 KB, patch)
2012-04-25 14:33 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (117.95 KB, patch)
2012-04-25 14:34 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (117.95 KB, patch)
2012-04-25 14:36 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (16.32 KB, patch)
2012-07-17 18:59 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (16.53 KB, patch)
2012-07-17 21:48 UTC, Elliott Davis
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (16.59 KB, patch)
2012-07-18 11:25 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (12.74 KB, patch)
2012-09-18 15:53 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (12.68 KB, patch)
2013-01-01 23:58 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs (12.73 KB, patch)
2013-01-15 16:21 UTC, Ed Veal
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jane Wagner 2010-08-02 15:46:42 UTC
The XSLT results list does not show shelving location (the non-XSLT display does).  For both shelving location and call number, some sites want either/both to show, while sites with 30-40 branches may want to declutter the display.  I'm proposing to add separate sysprefs to control whether or not XSLT results list displays (a) shelving location and (b) call number.  Comments?  Suggestions?
Comment 1 Owen Leonard 2010-08-02 15:57:48 UTC
There is already an existing system preference similar to this: OPACItemsResultsDisplay. A first step would be to make this preference apply to the XSLT results as well.

If it's necessary to add separate controls for shelving location and call number, then the scope of this bug should be expanded to include both XSLT and normal results, and deprecate the OPACItemsResultsDisplay preference.

IMO.
Comment 2 Nicole C. Engard 2010-08-02 19:50:07 UTC
I have no preference on how it's done, but I do agree that it needs to be 2 prefs instead of just one.  Some people only want one or the other, not both to show.
Comment 3 Elliott Davis 2011-06-26 21:08:54 UTC Comment hidden (obsolete)
Comment 4 Nicole C. Engard 2011-06-29 19:30:06 UTC
Elliott,

I was testing this and I have 2 changes I recommend:

1. instead of the preference defaulting to 'show' it should default to 'don't show' since that's the way it is now
2. the sentence should not have the word 'Show' in it since that's chosen in the pull down.

Off to test the functionality now.

Nicole
Comment 5 Nicole C. Engard 2011-06-29 19:36:46 UTC Comment hidden (obsolete)
Comment 6 Nicole C. Engard 2011-06-29 19:37:20 UTC
Marking failed QA until the minor errors are fixed.
Comment 7 Elliott Davis 2011-06-30 21:42:13 UTC Comment hidden (obsolete)
Comment 8 Nicole C. Engard 2011-07-01 00:36:11 UTC
Elliott,

Is a default value of '2' right for this preference? Isn't '0' OFF?

I tried to apply the new patch (is it a follow up) - and got this:

nengard@debian:~/kohaclone$ git am -3 -i -u bug5079.patch
Commit Body is:
--------------------------
bug 5079
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying: bug 5079
Using index info to reconstruct a base tree...
<stdin>:68: trailing whitespace.
               
<stdin>:69: trailing whitespace.
               
<stdin>:90: trailing whitespace.
                     <span class="available">
<stdin>:101: trailing whitespace.
                 
<stdin>:115: trailing whitespace.
                 
warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging installer/data/mysql/en/mandatory/sysprefs.sql
CONFLICT (content): Merge conflict in installer/data/mysql/en/mandatory/sysprefs.sql
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/opac.pref
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/opac.pref
Auto-merging koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACResults.xsl
CONFLICT (content): Merge conflict in koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACResults.xsl
Failed to merge in the changes.
Patch failed at 0001 bug 5079
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
nengard@debian:~/kohaclone$
Comment 9 Nicole C. Engard 2011-07-01 00:40:33 UTC
nevermind - i need to apply both patches - testing now
Comment 10 Nicole C. Engard 2011-07-01 00:43:27 UTC
Okay, 2 changes need to be made:

#1 - the default preference should be set to '0' not '2' when set to 2 the value says 'don't show' but the location shows, you have to set it to 'show' and then back to 'don't show' to get it to hide the location.

#2 - see attached - if there is only one call number it's still not showing.
Comment 11 Nicole C. Engard 2011-07-01 00:43:45 UTC
Created attachment 4544 [details]
no call numbers on results
Comment 12 Nicole C. Engard 2011-07-01 00:44:01 UTC
Created attachment 4545 [details]
the second item does have a call number
Comment 13 Nicole C. Engard 2011-07-01 11:51:17 UTC
Just an update.  My second attachment was just to show that the item on the results page does have a call number - it's just not showing on the results page. I do know that the patch doesn't touch the bib detail display.

Nicole
Comment 14 Elliott Davis 2011-07-01 18:49:48 UTC Comment hidden (obsolete)
Comment 15 Paul Poulain 2011-08-03 13:22:14 UTC
QA comment

3 things, major according to me:
* the item part of XSLT contains lacks many fields :
there's just homebranch, status and callnumber before this patch. I agree it should also contain the Location, but not only. There should be all items fields. I know libraries that would want the barcode (yes, on OPAC), or the inventory number.

* The XSLT is here to let the library define what she want in the XSLT right ? So, with location available, why not just locally add the field if you want it? 

* the 2nd patch also contains many reindenting, making impossible to see what is really new in the xsl file (paranoid mode : if you've added a link to a worm or something bad like this, I can't see it)

IAN = Proposing Failed QA.
Comment 16 Ian Walls 2011-08-03 16:21:49 UTC
Paul,


Point 1 is outside the scope of this bug; the goal here is to display all the locational information (Branch, shelving location and call number) so that a patron can find the materials within the library.  A separate bug report would need to be filed to display other types on information on the OPAC search results.

Point 2:  making local changes to the XSLT is not recommended, because it makes upgrading more difficult.  I've got another development being spec'ed out now to make it possible for users to specify their own XSLT, so this kind of customization could be handled locally without altering core Koha files.  Unfortunately, that's not ready yet.

Point 3:  the whitespaces issues do need to be resolved, yes.  My plan is to squash these two commits, along with a third commit that addresses the following issue:

the current version of this patch will still show the Location(s) line if there are no items attached, but there will of course be no data.  I recommend that in this case, the line not be displayed.

Additionally, the Branchcode/Shelving Location/Callnumber combination should not be keyed based on status.  In fact, any status other than "available" should be ignored, since items that are checked out, in transit, damaged, lost, etc are not actually on the shelf as expected.  I believe adding an xsl:key on homebranch + location + itemcallnumber will help with this.


So my ruling is this has not Failed QA, but is not yet complete.  It will need to be so by Aug 15th.
Comment 17 Elliott Davis 2011-08-03 21:37:43 UTC
Ian,

I went ahead and applied my old patch to get us up and running before the 15th.  It's not a giant push to get it integrated into master by then since Chris stepped me through what I was doing wrong.

I will have to agree with Ian on points one and two.  I will also have to apologize for the spacing.  I had emacs set up to auto-tab files i was editing.  I have turned it off so that shouldn't happen again.
Comment 18 Paul Poulain 2011-08-04 08:05:41 UTC
Ian

Point 1 = agreed, but Eliott, while rewriting this patch, if you have some time to embeed all items fields instead of just adding 1, it would be perfect (I wouldn't object anything if you don't do it though)

Point 2 = Ian: BibLibre already has this feature on biblibre/master. See 4032, seems this patch has been lost in limbos :(
Comment 19 Chris Cormack 2011-08-04 08:26:37 UTC
Yep 4032 never had a patch based on master attached to it. So not so much lost as never submitted, (As noted on bug 4032)

As far as point one goes, I would prefer separate bugs and patches for others. 
Big patches are hard to test as we have learnt, separate bugs and patches make for much easier testing and thus go into master a lot faster. Adding it to this would mean the syspref would now not switch on just location information, but a lot of other stuff that libraries may not want.

Point 3 will need to be resolved.
Comment 20 Paul Poulain 2011-08-05 10:21:17 UTC
Chris =
Yep 4032 never had a patch based on master attached to it. So not so much lost
as never submitted, (As noted on bug 4032)

=> we made something, it's not in master. It has been lost in limbos (limbos starting at git.biblibre.com, we failed to submit it correctly)

Ian =
The general idea is still valid though = if you want to use what we already made, just ask, i'll investigate. If you've/prefer to make from scratch, too bad, duplicate effort...
Comment 21 Paul Poulain 2011-08-05 10:24:29 UTC
wow... big failure: what hdl said (result list can't be different for OPAC and staff) has been fixed = you can have 4 stylesheets : staff result/staff detail/opac result/opac detail
Comment 22 Ian Walls 2011-08-05 12:56:32 UTC
Since this change is more narrowly focused, and has already initial patches as well as identified areas to improve, I recommend we proceed with this patch.  Work on bug 4032 can still be done, but it is independent of this particular feature.
Comment 23 Paul Poulain 2011-10-06 12:37:06 UTC
QA comment:
* marking Failed QA until the space changes in XSLT have been removed
* the syspref behaviour has changed and now new sysprefs must be provided in $KOHA/installer/data/mysql/sysprefs.sql
Comment 24 Elliott Davis 2011-10-22 17:22:09 UTC
Paul_p: For the whitespace issue have you considered using "git merge -s recursive -Xignore-space-change"

As for the change of sysprefs I'm assuming this file was moved from the mandatory folder.  I can patch this but I am currently working on bug 5549 so all of my work is based on that.  When it gets pushed to master I will continue my work on this bug.
Comment 25 Nicole C. Engard 2012-03-14 13:16:28 UTC
Any chance of seeing this fixed before the feature freeze?
Comment 26 Kyle M Hall 2012-04-25 14:06:31 UTC Comment hidden (obsolete)
Comment 27 Kyle M Hall 2012-04-25 14:33:19 UTC Comment hidden (obsolete)
Comment 28 Kyle M Hall 2012-04-25 14:34:47 UTC Comment hidden (obsolete)
Comment 29 Kyle M Hall 2012-04-25 14:36:13 UTC Comment hidden (obsolete)
Comment 30 Marcel de Rooy 2012-06-21 07:57:32 UTC
Could one of the patch authors sort out which patch should be tested and mark the others as obsolete? Thanks.
Comment 31 Jared Camins-Esakov 2012-07-07 16:00:47 UTC
There are three patches on this bug, and no response to Marcel's request... which patch(es) need testing?
Comment 32 Kyle M Hall 2012-07-08 12:32:07 UTC
My patch was a a full rewrite of Elliot's patch, as his sat here too long without testing any became very out of sync with master. I didn't obsolete his implementation out of courtesy, but since mine has already been signed off, it seems silly not to push forward with it.
Comment 33 Jared Camins-Esakov 2012-07-13 14:16:09 UTC
Thanks for clarifying which patch was which. Who signed off? Was this signed off?
Comment 34 Paul Poulain 2012-07-13 15:47:48 UTC
QA comment: 
 * seems that 99% of this patch is related to some indentation changes. That makes the patch too hard to QA.
Please provide a patch with changes more visible. You're welcomed to submit a follow-up just for fixing indentation, in this bug (no need to create a new bug just for that), but please provide 2 separate patches.


Other than this comment, I don't think anything wrong from QA POV (in other files than MARC21slim2OPACResults.xsl)

marking failed QA and requesting 2 separate patches
Comment 35 Paul Poulain 2012-07-13 15:48:03 UTC
sorry, failed QA, not passed QA...
Comment 36 Jared Camins-Esakov 2012-07-17 18:59:36 UTC Comment hidden (obsolete)
Comment 37 Elliott Davis 2012-07-17 21:48:55 UTC Comment hidden (obsolete)
Comment 38 Kyle M Hall 2012-07-18 11:25:55 UTC Comment hidden (obsolete)
Comment 39 Paul Poulain 2012-07-23 15:31:20 UTC
mmm... either I missed something, either some parts of this patch must still be removed.
Now, with bug 4032, each library has the opportunity to have his own XSLT.
So, I think that:
 * the XSLT.pm part is OK = we must send the datas to the XSLT
 * the XSLT update is OK = provide the information in the default XSLT
 * the systempreference is KO = if a library don't want the shelving location, let's change the XSLT (please don't say "it's harder to update a XSLT than updating a syspref", that's the case for any display change: some libraries want the barcode, some don't)

I -strongly- think providing the info by default is better. If you think it's not, then just update XSLT.pm and let libraries wanting the info have their own syspref.

conclusion: FAUSP leader striked again ;-)
Comment 40 Chris Cormack 2012-07-24 01:31:36 UTC
(In reply to comment #39)
> mmm... either I missed something, either some parts of this patch must still
> be removed.
> Now, with bug 4032, each library has the opportunity to have his own XSLT.
> So, I think that:
>  * the XSLT.pm part is OK = we must send the datas to the XSLT
>  * the XSLT update is OK = provide the information in the default XSLT
>  * the systempreference is KO = if a library don't want the shelving
> location, let's change the XSLT (please don't say "it's harder to update a
> XSLT than updating a syspref", that's the case for any display change: some
> libraries want the barcode, some don't)
> 
> I -strongly- think providing the info by default is better. If you think
> it's not, then just update XSLT.pm and let libraries wanting the info have
> their own syspref.
> 
I disagree strongly.

The convention is always don't change the behaviour people are used to, but let them switch a syspref to change it. This we have done for ever. 
I see no reason to change it because one person doesn't like system preferences.
Comment 41 Katrin Fischer 2012-07-24 04:32:07 UTC
I agree too that a system preference is the way to go here. It's not useful for every library to show the shelving location an callnumber. I am thinking about libraries with lots of branches for example that don't want all that information cluttering up the result list. And you can't expect them to edit XSLT files to get back what they already had - like Chris said, this is not convention.
Apart from that using your own XSLT files has a number of downsides, even if it's easier with the new syspref. They will never get updated to get new features introduced for XSLT and if you have multiple languages activated maintaining them gets even more of a pain. It's ok for me that it's possible, but we shouldn't make it the expected standard.
Comment 42 Nicole C. Engard 2012-08-14 10:45:03 UTC
Will this development also control the show of location on the lists?
Comment 43 Owen Leonard 2012-09-14 13:47:50 UTC
Applying: Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs
error: patch failed: C4/XSLT.pm:187
error: C4/XSLT.pm: patch does not apply
error: patch failed: installer/data/mysql/sysprefs.sql:375
error: installer/data/mysql/sysprefs.sql: patch does not apply
error: patch failed: installer/data/mysql/updatedatabase.pl:5536
error: installer/data/mysql/updatedatabase.pl: patch does not apply
error: patch failed: koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACResults.xsl:27
error: koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACResults.xsl: patch does not apply
Comment 44 Kyle M Hall 2012-09-18 15:53:15 UTC Comment hidden (obsolete)
Comment 45 Jared Camins-Esakov 2013-01-01 23:58:16 UTC Comment hidden (obsolete)
Comment 46 Jared Camins-Esakov 2013-01-02 00:01:09 UTC
As RM for 3.12, I am reversing Paul's decision to fail this on the basis of the syspref. I consider the additional syspref both useful and necessary, and will push this patch if there is no other quality-based objection to this code.
Comment 47 Ed Veal 2013-01-15 16:21:09 UTC
Created attachment 14605 [details] [review]
Bug 5079 - Make display of shelving location and call number in XSLT results controlled by sysprefs

* Don't show the Location line if there are no copies available, since it
  will inevitably be blank

* Also, don't show locations for Checked Out, Lost, Damaged, Withdrawn,
  On Hold or In transit items; it doesn't really make sense, since the
  items aren't actually there, and it results in repetitive listing of
  the shelving location

* Added system preference to display shelving location of an item on opac
  results. The system preference is called OpacItemLocation. I also moved
  the call number to a new line called Location along with the shelving
  location if it is enabled.

To Test:
  1) Run database update script to add syspref.
  2) Set OpacItemLocation to show locations or collection codes on the
     opac-search page.

  If it is working you should see the shelving location of the item
  before the call number. Multiple home branch shelving locations
  are seperated by a pipe character ( i.e. '|' ).

Based on code by Elliot Davis <tdavis@uttyler.edu>

Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Works as advertised.

Signed-off-by: Ed Veal <ed.veal@bywatersolutions.com>
Comment 48 Jared Camins-Esakov 2013-03-06 20:13:03 UTC
Per comment 46, I consider this to have passed QA, as the only objection to the code is one that I do not recognize as grounds for refusal from inclusion in 3.12.
Comment 49 Jared Camins-Esakov 2013-03-07 16:06:04 UTC
This patch has been pushed to master.
Comment 50 Mathieu Saby 2013-04-18 11:52:57 UTC
BZ 5079 only changed XSLT file for MARC21.
So I suppose a followup for unimarc is needed?
And this followup must take into account BZ9995 that fixes a regression introduced by BZ 5079.

M. Saby
Comment 51 David Cook 2014-05-09 00:27:06 UTC
Just poking around on the XSLTs, and noticed that this system preference doesn't work as it should.

1) The XSL logic for showing "location" and "ccode" is wrong. Those should be "xsl:if" tests rather than "xsl:when" tests. Currently, if you have "available" items and "reference" items, only locations/ccodes for the "available" items will be shown. The "xsl:choose" will stop at the first successful "xsl:when" test and then ignores the rest. 

'tis an easy fix.

2) The "reference" code is missing a test for $OPACItemLocation='callnum'". 

(It also doesn't support "singleBranchMode", although "singleBranchMode" on the XSLTs doesn't necessarily make much sense to me either...since it still organizes by branch without showing the branch...)
Comment 52 David Cook 2014-05-09 00:28:18 UTC
(In reply to David Cook from comment #51)
> Just poking around on the XSLTs, and noticed that this system preference
> doesn't work as it should.
> 
> 1) The XSL logic for showing "location" and "ccode" is wrong. Those should
> be "xsl:if" tests rather than "xsl:when" tests. Currently, if you have
> "available" items and "reference" items, only locations/ccodes for the
> "available" items will be shown. The "xsl:choose" will stop at the first
> successful "xsl:when" test and then ignores the rest. 
> 
> 'tis an easy fix.
> 
> 2) The "reference" code is missing a test for $OPACItemLocation='callnum'". 
> 
> (It also doesn't support "singleBranchMode", although "singleBranchMode" on
> the XSLTs doesn't necessarily make much sense to me either...since it still
> organizes by branch without showing the branch...)

To clarify point #2, if you have $OPACItemLocation set to something other than 'callnum', your "reference" items will still show 'callnum'. If you just have "reference" items, you will get your callnumber in the availability section and the location section.
Comment 53 David Cook 2014-05-09 00:32:56 UTC
To clarify point #1, I was referring to these tests:

<span class="label">Location(s): </span>
<xsl:when test="count(key('item-by-status', 'available'))>0">

<xsl:when test="count(key('item-by-status', 'reference'))>0">

They should be:

<xsl:if test="count(key('item-by-status', 'available'))>0">

<xsl:if test="count(key('item-by-status', 'reference'))>0">

Since we want to be able to trigger both.

--

This whole block of code is wrapped in an unnecessary xsl:choose as well...
Comment 54 David Cook 2014-05-09 01:02:46 UTC
To be even more of a pain...

It's also worth mentioning that the following code doesn't do what one would expect either:

<xsl:for-each select="$available_items[generate-id() = generate-id(key('item-by-status-and-branch', concat(items:status, ' ', items:homebranch))[1])]">
                            <xsl:choose>
                                <xsl:when test="$OPACItemLocation='location'"><b><xsl:value-of select="concat(items:location,' ')"/></b></xsl:when>
                                <xsl:when test="$OPACItemLocation='ccode'"><b><xsl:value-of select="concat(items:ccode,' ')"/></b></xsl:when>
                            </xsl:choose>
                            <xsl:if test="items:itemcallnumber != '' and items:itemcallnumber"> <xsl:value-of select="items:itemcallnumber"/></xsl:if>
                            <xsl:choose><xsl:when test="position()=last()"><xsl:text>. </xsl:text></xsl:when><xsl:otherwise><xsl:text>, </xsl:text></xsl:otherwise></xsl:choose>
                        </xsl:for-each>

1. Items are grouped by status and branch. That means that you will only ever get 1 entry for available items at branch X.

As a result, "concat(items:location,' ')" is pointless, because there is only ever going to be one item and thus one items:location. 

'select="$available_items[generate-id() = generate-id(key('item-by-status-and-branch', concat(items:status, ' ', items:homebranch))[1])]"' means that we only get the first available item in the item-by-status-and-branch. If you change [1] to [2], you'll see the data for the second item instead.

2. Since we only get 1 entry for available items at branch X, we're not going to be showing all the locations, ccodes, and callnumbers available.

If we want to get the locations, ccodes, and callnumbers, we need to create different sets of named keys like:

<xsl:key name="item-by-status-and-branch-and-location" match="items:item" use="concat(items:status, ' ', items:homebranch, ' ', items:location)"/>
<xsl:key name="item-by-status-and-branch-and-ccode" match="items:item" use="concat(items:status, ' ', items:homebranch, ' ', items:ccode)"/>
<xsl:key name="item-by-status-and-branch-and-itemcallnumber" match="items:item" use="concat(items:status, ' ', items:homebranch, ' ', items:itemcallnumber)"/>

Currently, if you have 2 available items with different locations/ccodes at branch X, only the first from the MARCXML returned by Zebra will be shown. 

That seems quite undesirable to me. 

--

It's worth mentioning that this problem exists elsewhere in the XSLT when we're trying to show call number as well.
Comment 55 David Cook 2015-10-19 04:38:03 UTC
Upgrading a system now, so I'm looking at XSLT improvements, but I'm guessing problems I highlighted in the past are still problems...

Might look at these again soon...
Comment 56 Marcel de Rooy 2018-08-23 11:01:24 UTC
(In reply to David Cook from comment #54)
> 'select="$available_items[generate-id() =
> generate-id(key('item-by-status-and-branch', concat(items:status, ' ',
> items:homebranch))[1])]"' means that we only get the first available item in
> the item-by-status-and-branch. If you change [1] to [2], you'll see the data
> for the second item instead.

See bug 21260.