June 2012 - Koha-bugs - lists.koha-community.org

[Bug 6535] New: Dates in notices should be syspref formatted
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '13

04 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6535 Bug #: 6535 Summary: Dates in notices should be syspref formatted Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Notices AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Any date field being parsed into the notice should be formatted accounting to dateformat system preference. A change made to C4::Letters::parseletter would handle this for every letter coming though. -- 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 5172] New: Use other name rather than first name when referring to the user
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '13

03 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5172 Summary: Use other name rather than first name when referring to the user Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In the OPAC, the 'Other Name' field should be used when referring to the user, if it's been supplied. For example, "Mr Firstname Surname" should be "Mr Othername Surname" if there is a defined Othername. -- 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 16

[Bug 7669] New: Search Results Multiple Cover Image HTML & CSS
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '13

03 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7669 Priority: P5 - low Change sponsored?: --- Bug ID: 7669 Assignee: oleonard(a)myacpl.org Summary: Search Results Multiple Cover Image HTML & CSS QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: ssammons(a)npelem.com Hardware: All Status: NEW Version: rel_3_6 Component: OPAC Product: Koha Created attachment 8065 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8065&action=edit Patch of my changes to opac_results.tt and opac.css Looks at the code for the images in the template I notices some were raw images, some were encased in <div> tags, and no-images were in <spans> As per my comments in bug 7594 I added classes to the elements to make then more easily modified by the end user through the OPAC CSS options. Also, all images and no-images now have float:left (this was in the .thumbnail class). I combines the thumbnail elements into the .no-image{} class. It does not have div.no-image like the still active span.no-image, because that is an element specific class and thus any setting in it over-ride user settings. So, it has to stay a simply .no-image. Images "<img>" now have a class thumbnail_image. This was in keeping with consistent and unique element classes. Thumbnail is used by all the <div> elements. Here are the new classes I have added, that are vendor/company specific: /* New Classes for Thumbnail Images */ .thumbnail_image { /* specific class for the actual <img> tag */ } /* specific classes for thumbnails */ .opac_thumb, .amazon_thumb, .google_thumb, .syndetics_thumb, .openlibrary_thumb, .bakertaylor_thumb{ } /* specific classes for no-image */ .amazon_no, .google_no, .openlibrary_no, .bakertaylor_no{ } Example Code to see why: /*examples how a specific class works*/ div.amazon_no{ /*Amazon no image [seem broken in code]*/ border: 1px solid #FFA500; /*amazon is ornage*/ } .google_thumb, .google_no{/*Google no image*/ border-top: 2px solid #F00; border-right: 2px solid #080; border-bottom: 2px solid #FF0; border-left: 2px solid #00F; padding: 2px; } .openlibrary_no{ background: url(http://openlibrary.org/images/logo_IA-sm.png) right center no-repeat; color: #00F; text-align: left; } You can also view an image here...http://ww.screencast.com/t/vPwtSYmZa4v I am attaching my patch -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 6556] New: The popup menu in the Z39.50 search results doesn't point to the correct record.
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '13

03 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6556 Bug #: 6556 Summary: The popup menu in the Z39.50 search results doesn't point to the correct record. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: fcapovilla(a)live.ca QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Created attachment 4565 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4565 Corrects the popup menu links in the z3950 search results. In the results of a Z39.50 search, if a result is clicked, a small popup menu appears with the options "Preview MARC","Preview Card","Import","X". If we compare the URL of the "Preview Marc" menu option and the URL of the "MARC" link on the same line, we can see that the "importid" is not the same in the two URLs. The importid in the popup menu seems to always be the importid of the last item of the results list. Patch attached that corrects the problem. -- 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 14

[Bug 5233] New: Allow a dropdown for zipcode that auto-fills in the field
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '13

02 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5233 Summary: Allow a dropdown for zipcode that auto-fills in the field Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 This is similar to the "City, State" one that's there already, however only does the zipcode. It pulls from the authorised values in the 'POSTAL' category, the value is the code, the description is the name. I'm unsure if this is likely to be wanted upstream, but it's here if anyone wants it. -- 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 7913] New: Automatically receive sdrials issues
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '13

02 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7913 Priority: P5 - low Change sponsored?: --- Bug ID: 7913 Assignee: colin.campbell(a)ptfs-europe.com Summary: Automatically receive sdrials issues QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: savitra.sirohi(a)osslabs.biz Hardware: All Status: NEW Version: rel_3_8 Component: Serials Product: Koha Currently in Koha, each issues is marked "arrived" manually. This can be a lot of work in libraries with a large number of serial subscriptions. Instead, automatically mark issues as received. Issues that are not received will be marked "pending" manually. Create screens that display issues to be received across serials, set default to "arrived", user can select the ones that have not arrived and mark them as "pending". -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 8153] New: Bulk serial receive
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '13

02 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8153 Priority: P5 - low Change sponsored?: --- Bug ID: 8153 Assignee: colin.campbell(a)ptfs-europe.com Summary: Bulk serial receive Severity: enhancement Classification: Unclassified OS: All Reporter: shinoy.m(a)osslabs.biz Hardware: All Status: NEW Version: master Component: Serials Product: Koha -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 5250] New: Various enhancements to web based checkouts
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '13

02 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5250 Summary: Various enhancements to web based checkouts Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Self checkout AssignedTo: gmcharlt(a)gmail.com ReportedBy: cnighswonger(a)foundations.edu QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Among various layout enhancements this patch adds two web-based checkout system preferences: 1. WebBasedSelfCheckTimeout - This preference sets the time in milliseconds beyond which the patron's session will time out and they will be required to re-scan/re-enter their card number. The timer is reset on each page load. Previously this was hard coded at 120000 milliseconds or 120 seconds. 2. WebBasedSelfCheckHeader - This preference allows the library to insert its own custom header at the top of the web-based self checkout service pages. Among the misc changes are the inclusion of opac.css in the web-based self checkout template since it is technically part of the opac. sco.css is applied last so that those settings override those in opac.css. The online help is modified to pop up a window rather than requiring the user to navigate away from the interface. -- 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 10

[Bug 7721] New: Global xslt parsing in XSLT.pm under mod_perl
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '13

02 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7721 Priority: P5 - low Change sponsored?: --- Bug ID: 7721 Assignee: oleonard(a)myacpl.org Summary: Global xslt parsing in XSLT.pm under mod_perl QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: pelletiermaxime(a)gmail.com Hardware: All Status: NEW Version: rel_3_6 Component: OPAC Product: Koha When running ModPerl::PerlRunPrefork, the wrong xls file is used in opac-search and opac-detail. There is a global variable $stylesheet above the function XSLTParse4Display that keeps the cached xsl files in memory. The problem is that with mod_perl it says in memory, so it sometimes use detail xls in search and vice-versa. Patch to follow that fixes it by transforming $stylesheet into a hash to have a cache for each xls file. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 5806] New: Search results display items for all locations when the SearchMyLibrary first system pref is activated
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '13

02 Jan '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5806 Bug #: 5806 Summary: Search results display items for all locations when the SearchMyLibrary first system pref is activated Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC Comments AssignedTo: gmcharlt(a)gmail.com ReportedBy: peter.lorimer(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org When searchMyLibraryFirst system pref is activated, although the results are filtered, the search results show items available in all locations. On the detail page items from all locations are also being displayed. A good enhancement would be an additional pref called SearchMyLibraryOnly where as well as the results, the detail summaries and the locations the item is available (in the search result content) are also filtered. A user should have the ability to choose a library to search or to log in, when the user logs in that users library is selected, other wise the user can select a library or opt to search all libraries If you choose SearchMyLibraryOnly you should only see items from tha selected library and nothing else. -- 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 13