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 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 ---------------------------------------------------------------------------- Attachment #6699|0 |1 is obsolete| | --- Comment #7 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> 2011-12-11 13:16:05 UTC --- Created attachment 6706 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6706 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. -- 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 --- Comment #6 from Koustubha Kale <kmkale(a)anantcorp.com> 2011-12-11 08:07:50 UTC --- Hi, Tried the patch. Applies cleanly except for a few whitespace errors. But when I try to run the automic update installer/data/mysql/atomicupdate/local_cover_images.pl I got a permission denied. So executable permissions are needed for this file. After I did that the patch works. Also the uploaded image does not show up in the intranet search page. It does show up in the OPAC search page. In both intranet & OPAC the uploaded images DO show up under the images tab in detail page. regards kmkale -- 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 --- Comment #5 from Jared Camins-Esakov <jcamins(a)cpbibliography.com> 2011-12-10 19:27:24 UTC --- Created attachment 6699 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6699 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 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. -- 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 2629] Diacritics not being ignored when searching
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '11

10 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2629 --- Comment #29 from Albert Oller <ago(a)bywatersolutions.com> 2011-12-09 21:03:35 UTC --- Hi Jared, The original problem reported was for this: Anam ċara from Harrison Memorial Library (Carmel) Anam ċara : (Record no. 62385) [ view plain ] 000 -LEADER fixed length control field 00991nam a2200325Ia 4500 001 - CONTROL NUMBER control field ocm40357390 100 1# - MAIN ENTRY--PERSONAL NAME Personal name O'Donohue, John, Dates associated with a name 1956- 245 10 - TITLE STATEMENT Title Anam ċara : Remainder of title a book of Celtic wisdom / Statement of responsibility, etc John O'Donohue The ċ was the only character reported as causing a problem, but I found a few extra characters that were missing, that I added in to prevent future tickets. Thanks, Albert -- 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 3383] Item due reminder digests - cannot display title information
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '11

09 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3383 Ian Walls <ian.walls(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian.walls@bywatersolutions. | |com Version|rel_3_0 |master --- Comment #1 from Ian Walls <ian.walls(a)bywatersolutions.com> 2011-12-09 01:25:46 UTC --- The issue of <<branch.*>> tokens not working in digests is due to an ambiguity of what branch to use, and the potential multiplicity of branches that comes with checkouts from multiple branches. The only constant branchcode on a per-notice basis I could see would be the patron's branch. Can anyone think of a case where a different branch's contact information should be parsed into a PREDUEDGST or DUEDGST notice? -- 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 6956] New: lists printing messed up
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '11

09 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6956 Bug #: 6956 Summary: lists printing messed up Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5674 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5674 printed version of the list When printing lists there is a very large left margin that smooches all the text to right. -- 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.

1 5

[Bug 4813] New: implement XSLTResultsDisplay
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '11

08 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4813 Summary: implement XSLTResultsDisplay Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 This system preference exists but is not functional yet. To complete this feature, stylesheets need to be written for format bibliographic records in the staff interface search results display. -- 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.

1 1

[Bug 7281] New: Hide some lists (virtual shelves) from OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '11

08 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7281 Bug #: 7281 Summary: Hide some lists (virtual shelves) from OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Virtual Shelves AssignedTo: gmcharlt(a)gmail.com ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: ian.walls(a)bywatersolutions.com For use in our library, it would be useful if we could hide a specific public (or open) list from the opac. This makes it possible to share a list between users of the staff client only. For that use I added a field hidefromopac in the shelves table. And modified a few functions in VirtualShelves.pm and calls to these functions in catalogue/search.pl, virtualshelves/addbybiblionumber.pl and C4/Auth.pm. Patch is forthcoming. -- 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 4

[Bug 4530] Circulation & fines rules aren't always applied from most specific to less specific
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '11

08 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4530 Srdjan Jankovic <srdjan(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Does not apply |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. You are watching all bug changes.

1 0

[Bug 4530] Circulation & fines rules aren't always applied from most specific to less specific
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '11

08 Dec '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4530 Srdjan Jankovic <srdjan(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #5329|0 |1 is obsolete| | --- Comment #11 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> 2011-12-08 03:53:19 UTC --- Created attachment 6656 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6656 patch -- 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