http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #1 from Owen Leonard <oleonard@myacpl.org> --- 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #3 from Elliott Davis <tdavis@uttyler.edu> 2011-06-26 21:08:54 UTC --- Created attachment 4523 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4523 Patch to add/remove shelving location in xslt opac-search Added system preference to display shelving location of an item on opac reults. 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: run database update script to add syspref. Enable OpacItemLocation to show locations 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 separated by a |. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #5 from Nicole C. Engard <nengard@gmail.com> 2011-06-29 19:36:46 UTC --- Created attachment 4534 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4534 errors On testing when the preference is turned off it is not showing the call number for items that are checked out. If there is no data the 'locations' area shouldn't print to the screen - it's just confusing. In this instance though I think the call number should show, cause the record has one. It's not showing call numbers if the first call number is blank. The second result in this screenshot has a call number on the second item - but not the first. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Elliott Davis <tdavis@uttyler.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4523|0 |1 is obsolete| | -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Elliott Davis <tdavis@uttyler.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Failed QA |Needs Signoff -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Needs Signoff |Does not apply --- Comment #8 from Nicole C. Engard <nengard@gmail.com> 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$ -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Nicole C. Engard <nengard@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Does not apply |Failed QA --- Comment #10 from Nicole C. Engard <nengard@gmail.com> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #12 from Nicole C. Engard <nengard@gmail.com> 2011-07-01 00:44:01 UTC --- Created attachment 4545 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4545 the second item does have a call number -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Elliott Davis <tdavis@uttyler.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4543|0 |1 is obsolete| | -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Elliott Davis <tdavis@uttyler.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Failed QA |Needs Signoff -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Ian Walls <ian.walls@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4523|0 |1 is patch| | Attachment #4523|application/octet-stream |text/plain mime type| | -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #16 from Ian Walls <ian.walls@bywatersolutions.com> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #18 from Paul Poulain <paul.poulain@biblibre.com> 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 :( -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #20 from Paul Poulain <paul.poulain@biblibre.com> 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... -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #22 from Ian Walls <ian.walls@bywatersolutions.com> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #24 from Elliott Davis <tdavis@uttyler.edu> 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. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #25 from Nicole C. Engard <nengard@gmail.com> --- Any chance of seeing this fixed before the feature freeze? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Elliott Davis <tdavis@uttyler.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tdavis@uttyler.edu Assignee|oleonard@myacpl.org |tdavis@uttyler.edu -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4543|1 |0 is obsolete| | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #27 from Kyle M Hall <kyle.m.hall@gmail.com> --- Created attachment 9297 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9297&action=edit 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) Enable OpacItemLocation to show locations 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. '|' ). -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #9298|0 |1 is obsolete| | --- Comment #29 from Kyle M Hall <kyle.m.hall@gmail.com> --- Created attachment 9299 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9299&action=edit 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) Enable OpacItemLocation to show locations 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. '|' ). -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|PATCH-Sent (DO NOT USE) |P5 - low --- Comment #30 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Could one of the patch authors sort out which patch should be tested and mark the others as obsolete? Thanks. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4547|0 |1 is obsolete| | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Kyle M Hall <kyle.m.hall@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4543|0 |1 is obsolete| | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Elliott Davis <tdavis@uttyler.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|tdavis@uttyler.edu |elliott@bywatersolutions.co | |m -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA QA Contact|koha-bugs@lists.koha-commun |paul.poulain@biblibre.com |ity.org | --- Comment #34 from Paul Poulain <paul.poulain@biblibre.com> --- 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 -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #37 from Elliott Davis <elliott@bywatersolutions.com> --- Created attachment 10913 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10913&action=edit 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. '|' ). Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Rebased on latest master, removed the reformatting, and changed the syspref to be a choice between showing the call number only, the location, and the collection code. Signed-off-by: Elliott Davis <elliott@bywatersolutions.com> Works as Advertised. I would like to see the logic added to differenciate between multiple locations and a single location for the word 'location(s)' but that goes beyond the scope of this ticket. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #10913|0 |1 is obsolete| | --- Comment #38 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 10929 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10929&action=edit 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. '|' ). Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Rebased on latest master, removed the reformatting, and changed the syspref to be a choice between showing the call number only, the location, and the collection code. Signed-off-by: Elliott Davis <elliott@bywatersolutions.com> Works as Advertised. I would like to see the logic added to differenciate between multiple locations and a single location for the word 'location(s)' but that goes beyond the scope of this ticket. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #39 from Paul Poulain <paul.poulain@biblibre.com> --- 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 ;-) -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #41 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #42 from Nicole C. Engard <nengard@gmail.com> --- Will this development also control the show of location on the lists? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #10929|0 |1 is obsolete| | --- Comment #44 from Kyle M Hall <kyle@bywatersolutions.com> --- Created attachment 12317 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=12317&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Magnus Enger <magnus@enger.priv.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@enger.priv.no See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=5229, | |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=9028 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #12317|0 |1 is obsolete| | --- Comment #45 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- Created attachment 14355 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=14355&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Ed Veal <ed.veal@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #14355|0 |1 is obsolete| | --- Comment #47 from Ed Veal <ed.veal@bywatersolutions.com> --- Created attachment 14605 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=14605&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to Master --- Comment #49 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- This patch has been pushed to master. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 mathieu saby <mathieu.saby@univ-rennes2.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathieu.saby@univ-rennes2.f | |r --- Comment #50 from mathieu saby <mathieu.saby@univ-rennes2.fr> --- 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 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #52 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5079 --- Comment #54 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes.