Bug 2165 - Add XSL Support for Staff Client -- was: ISBN being truncated
Summary: Add XSL Support for Staff Client -- was: ISBN being truncated
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: rel_3_2
Hardware: PC All
: P3 normal (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 2771
  Show dependency treegraph
 
Reported: 2008-05-23 11:27 UTC by Nicole C. Engard
Modified: 2012-10-25 22:52 UTC (History)
6 users (show)

See Also:
Change sponsored?: 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 Chris Cormack 2010-05-21 00:47:19 UTC


---- Reported by nengard@gmail.com 2008-05-23 11:27:40 ----

The ISBN field needs to display the entire field on the OPAC book detail.  Also we need to show multiple ISBNs if there are multiple.  I've seen records with 6 ISBNs, 2 for ISBN10, 2 for ISBN13, 2 for Pbk - and unfortunately they should all display on the record.


Per Chat:

<nengard> detail page question - I don't have a sample of this - what happens if a book has more than one ISBN (020) or if the 020 has text in it - like 'pbk' etc?
 <owen> There does seem to be a problem with that display
 * owen looks
 <owen> Can anyone tell me how to run fines2.pl manually?
 <owen> nengard: It seems like ISBN is truncated by opac-detail if there is 'extra' text: http://oleonard.dev.kohalibrary.com/cgi-bin/koha/opac-detail.pl?biblionumber=254
 <nengard> owen - bug?? cause I think it is - but what does everyone else think? also if there are 2 020 fields they should both show
 <nengard> and which 020 wins the battle? the first or the one that's numerically first?
 <owen> Yeah, it's a bug. It looks like it's because opac-detail pulls the isbn from the biblioitems table, and the isbn column in that table is limited to...what is it now? 13? 
 <nengard> 13



---- Additional Comments From kohabugs@agogme.com 2008-06-02 03:34:49 ----

All code using the ISBN should use all ISBNs.  That is all the code pulling inforation from Amazon, Google, etc should use all ISBNs.



---- Additional Comments From nengard@gmail.com 2008-06-02 04:10:53 ----

I agree! Right now I'll settle for the search finding the the right ISBNs :) I have other bugs reported relating to the fact that all ISBNs are not showing.



---- Additional Comments From kohabugs@agogme.com 2008-06-02 04:27:04 ----

OPAC detail should be pulling information directly from the MARC record including the appropriate distinctions for format such as pbk. etc.  Otherwise. OPAC detail specific SQL columns should store the information in a proper format for OPAC detail to display.  Only the holdings related fields in a MARC record would necessarily specify a single ISBN for a particular item.

There may also be a need to store a list of applicable ISBNs without the extra text from the same subfield such as the pbk. designation.  Incompleteness of ISBNs present in the record for a manifestation is problematic where the one present in a record does not match suitably for pulling data from Amazon, Google, etc  xISBN type services should be used to improve the prospects of finding  desirable matches.  The Amazon API may be queried for alternate bindings etc. which can then be used to obtain information which may not be associated with the ISBN present in the MARC record.



---- Additional Comments From nengard@gmail.com 2008-06-02 04:34:42 ----

I'm sorry! I got a bunch of bug emails last night.  I thought this was in relation to a different bug: #2098 which was about searching. You are right and they should all display!



---- Additional Comments From nengard@gmail.com 2008-06-02 11:35:46 ----

Just a note - the ISBN is also being truncated in the staff client on catalogue/detail.pl



---- Additional Comments From jmf@liblime.com 2008-07-14 12:05:43 ----

The solution to this is to use the XSL syspref which fixes the problem on the OPAC; but since the XSL isn't implemented on the staff side, the fix for this would require implementing XSL staff-side. I'll look into whether this is doable for 3.0, otherwise, we'll have to push it back to 3.2.



---- Additional Comments From jmf@liblime.com 2008-07-14 12:55:09 ----

This is gonna have to be a 3.2 issue, there's no clean way to handle links within our stylesheets ... what we need is an XSLT::Template so that we can pass in things like the path into the stylesheet, so that we don't have to replicate this whole XSL file for both OPAC and Staff ... or maybe they should be separate files, but either way, it's 3.2 or beyond.



---- Additional Comments From mjr@ttllp.co.uk 2008-07-15 06:14:12 ----

Why not pass parameters into the stylesheet in the $stylesheet->transform() call in C4::XSLT?  See perldoc XML::LibXSLT for tips.




---- Additional Comments From gmcharlt@gmail.com 2009-06-15 17:21:39 ----

Enabling XSLT bib display in the staff client has now been sponsored.



---- Additional Comments From frederic@tamil.fr 2009-06-15 17:30:13 ----

Please select XSL file accordingly to user selected language (staff and OPAC). Thanks.



---- Additional Comments From chris@bigballofwax.co.nz 2009-12-17 20:04:24 ----

This has been done and is working in master

# XSLT processing of some stuff                                                                                
if (C4::Context->preference("XSLTDetailsDisplay") ) {                                                          
    $template->param('XSLTDetailsDisplay' =>'1',                                                               
        'XSLTBloc' => XSLTParse4Display($biblionumber, $record, 'Detail','intranet') );                        
}  



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:47 UTC  ---

This bug was previously known as _bug_ 2165 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2165
This bug blocked bug(s) 2771 3921.

Actual time not defined. Setting to 0.0
CC member bchurch@ptfs.com does not have an account here
CC member daz-koha@zzzurn.com does not have an account here
CC member kdr@ckls.org does not have an account here
CC member kohabugs@agogme.com does not have an account here
CC member mjr@ttllp.co.uk does not have an account here