December 2011 - Koha-bugs - lists.koha-community.org

[Bug 1633] Add ability to take book cover images from local img db
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '11

13 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #6242|0 |1 is obsolete| | Attachment #6712|0 |1 is obsolete| | --- Comment #10 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> 2011-12-13 13:41:24 UTC --- Created attachment 6745 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6745 Bug 1633: Add support for uploading images to Koha A frequently-requested feature for Koha, especially by special libraries, is the ability to upload local cover images into Koha. This patch adds a bibliocoverimage table, and image handling code in the Koha::Images module. Key features of the implementation include: 1. The ability to have multiple cover images for a biblio 2. Handling for "full size" (800x600) and thumbnail-size (200x140) images 3. Uploading images directly from the record view The image display functionality by Koustubha Kale of Anant Corporation will follow in a second patch. Special thanks to Koustubha Kale and Anant Corporation for the initial implementation of local cover images, and to Chris Nighswonger of Foundation Bible College for his prior work on patron images. Developers who installed a previous version of the patch for bug 1633 may encounter errors in standard installs due to the Koha/Images.pm file not being installed properly. Please use this veresion instead. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 2156] Differences between English and French system preferences
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '11

13 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2156 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> 2011-12-13 06:40:51 UTC --- We are using one central file for system preferences now with the option to update some preferences to language specific values. I think this resolves 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. You are watching all bug changes.

1 0

[Bug 3216] UNIMARC author facets
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3216 --- Comment #10 from Frédéric Demians <frederic(a)tamil.fr> 2011-12-12 08:53:28 UTC --- (In reply to comment #7) > Unfortunately, as soon as I modify the 650 to be 650az, I run into a problem. > The facet displays properly, but if I try to use it, I get no results. This is > because, for now, Zebra does not allow multiple subfields to be concatenated > and thrown into a single index. Searching for "su-to: Cookery -- Pennsylvania" > will return nothing, even if that heading is plentiful in the catalog. > Currently, the only way to get to that heading would be "su-to: Cookery AND > su-to: Pennsylvania", or to use the linked authority record in subfield 9 It works with Zebra ICU tokenization. The 2nd patch allow to install a Zebra default.idx file working with word and phrase ICU indexes. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 3216] UNIMARC author facets
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3216 --- Comment #9 from Frédéric Demians <frederic(a)tamil.fr> 2011-12-12 08:51:02 UTC --- Created attachment 6716 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6716 ICU/CHR tokenization Word search with multi-part facets works properly only with Zebra ICU tokenization. This patch add a new question to Koha command line installer: Zebra has two methods to perform records tokenization and characters normalization: CHR and ICU. ICU is recommended for catalogs containing non-Latin characters. (chr, icu) [chr] How to test: - perl ./Makefile.PL - Try each possible value for new parameter - Take a look at zebradb/etc/default.idx file. Depending of the parameter you get this line: icuchain words-icu.xml or this one: charmap word-phrase-utf.chr -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 3431] Catalog by itemtype report pulling from holdingbranch
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3431 Chris Cormack <chris(a)bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 3431] Catalog by itemtype report pulling from holdingbranch
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3431 Chris Cormack <chris(a)bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5110|0 |1 is obsolete| | --- Comment #4 from Chris Cormack <chris(a)bigballofwax.co.nz> 2011-12-12 08:48:34 UTC --- Created attachment 6715 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6715 Fix for Bug 3431 - Catalog by itemtype report pulling from holdingbranch Plus several other fixes for this report no one uses: - Clarifying titles and breadcrumbs - Correcting terminology: branch -> library - Sorting library select field by library name - Displaying library name instead of code on output - Sorting results by itemtype description - Adding tablesorter to results Signed-off-by: Chris Cormack <chrisc(a)catalyst.net.nz> -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 3431] Catalog by itemtype report pulling from holdingbranch
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3431 --- Comment #3 from Chris Cormack <chris(a)bigballofwax.co.nz> 2011-12-12 08:46:40 UTC --- I agree this report is not used, but the changes made make it more useful to never use. Will sign off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 1633] Add ability to take book cover images from local img db
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 Jared Camins-Esakov <jcamins(a)cpbibliography.com> 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 watching all bug changes.

1 0

[Bug 1633] Add ability to take book cover images from local img db
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '11

12 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #6706|0 |1 is obsolete| | --- Comment #9 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> 2011-12-12 01:12:12 UTC --- Created attachment 6712 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6712 Bug 1633: Add support for uploading images to Koha A frequently-requested feature for Koha, especially by special libraries, is the ability to upload local cover images into Koha. This patch adds that ability. This counter-patch builds on the work by Koustubha Kale at Anant Corporation, but adds the following additional features: 1. Moves the code for handling image retrieval/saving into the Koha namespace 2. The ability to have multiple cover images for a biblio 3. Handling for "full size" (800x600) and thumbnail-size (200x140) images 4. A separate image viewer page 5. Javascript-based handling of cover image placement for the cover images in the OPAC (as opposed to static <img /> tags embedded into pages) 6. Local cover display in the staff client details view (there does not seem to be anywhere appropriate to put the cover image in the intranet search results) 7. Uploading images directly from the record view How to use/test : Assign user permission to the user Tools > (upload_local_cover_images Upload local cover images). In order to upload local images, login to the staff client. Go to Home > Tools > Upload Cover Images. Here you can upload cover images either singly or in bulk in the form of a zip file. If uploading singly, click on image file, browse the image from your local disk, type in the biblio number of the catalogue entry and press upload. If uploading in bulk as a zip file, the zip file must contain (in addition to cover images) one text file named either datalink.txt OR idlink.txt. This file should have mapping of biblionumber to image file name in the zip one per line with comma or tab as delimiters. For example: 1, scanned_cover_image_of_bib_no_1.jpg 2, scanned_cover_image_of_bib_no_1.jpg Cover images will be resized to a large image of 800x600 and a thumbnail of 200x140. Depending on the setting of AllowMultipleCovers, it is possible to upload multiple images for a single bibliographic record. However, even if multiple covers are permitted, you have the option of replacing the existing covers by checking the "Replace existing covers" option on the upload screen. 1. The patch adds a menu link in Tools from where you can upload local cover images 2. It adds a user permission to enable access control to this menu item under Tools 3. It adds a system preference OPACLocalCoverImages under Enhanced Content. This needs to be turned on to show local cover images in OPAC. Once you have uploaded local images, if you search for the biblio, the local cover should show up in search as well as search detail pages in the OPAC, and the details view in the Intranet. Koustubha Kale is working on another patch which will allow us to set a cover image source priority in system preferences, and which will then gracefully fail over to the next source if image is not available from the first choice source. Detailed test plan: 1. Install update (database updates are in installer/data/mysql/atomicupdate/local_cover_images.pl) 2. Enable LocalCoverImages and OPACLocalCoverImages in the Enhanced content preferences screen 3. Upload an image of type GIF, JPEG, PNG, or XPM either from the "Local Cover Image" tool and choosing "Image file" as its type and entering a valid biblionumber, or by viewing a record and clicking the "Upload Image" option under the Edit button in the toolbar 4. View the record in the Intranet and OPAC. The image should show up directly in OPAC search results and details, and there should be an "Images" tab on both the Intranet and the OPAC detail view 5. Upload another image and attach it to the same bibliographic record. 6. Confirm that the new image (only) shows up in the OPAC and Intranet 7. Change the AllowMultipleCovers to "Allow" in the Enhanced content preferences screen 8. Add several images to a bibliographic record 9. Confirm that they all show up in the "Images" tab on the Intranet and OPAC and only one shows up in the main display in the OPAC details and search results pages 10. Create a zip file containing at least one image and a text file "idlink.txt" with one or more lines that looks like this: 1, filename.jpg Replace the '1' with a valid biblionumber, and 'filename.jpg' with the name of the image file you are adding to the zip file 11. Upload the zip file from the "Local Cover Image" tool (being sure to choose "zip file" as the filetype) 12. Check that the image(s) have been attached to the appropriate bibliographic record(s) Special thanks to Koustubha Kale and Anant Corporation for the initial implementation of local cover images, and to Chris Nighswonger of Foundation Bible College for his prior work on patron images. Developers who installed a previous version of this patch may encounter errors in standard installs due to the Koha/Images.pm file not being installed properly. Please use this veresion instead. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 1633] Add ability to take book cover images from local img db
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '11

11 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 Jared Camins-Esakov <jcamins(a)cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jcamins(a)cpbibliography.com --- Comment #8 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> 2011-12-11 13:20:59 UTC --- The most recent patch resolves the whitespace errors and gives the updater executable permissions. Cover images are not added to the Intranet search results because I found them to be very aesthetically unappealing. Someone with more design ability could easily add them in a follow-up patch, if s/he wanted. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0