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

[Bug 3292] New: in opac branchcode should be replaced with name
by bugzilla-daemon＠liblime.com 12 Aug '09

12 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3292 Summary: in opac branchcode should be replaced with name Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: matthias.meusburger(a)biblibre.com ReportedBy: nicolas.morin(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- On opac-detail.pl, subscription tab, the branch shows the branch code -> "At branch: XYZ" It's not user friendly. Should be the branch's name -> "At branch: John Doe Library". -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 3173] New: Place Hold link shows various places in OPAC even if syspref RequestOnOpac is turned off
by bugzilla-daemon＠liblime.com 06 Aug '09

06 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3173 Summary: Place Hold link shows various places in OPAC even if syspref RequestOnOpac is turned off Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: ASSIGNED Severity: enhancement Priority: P5 Component: OPAC AssignedTo: jwagner(a)ptfs.com ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 If the syspref RequestOnOpac is turned off, the link to place a hold does not show in the detail page. However, the link is still present in the results list as well as in the basket and in lists. I'm sending a patch to remove the hold link from those pages as well. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3163] New: With XSLT on, OPAC does not put any spacing between 110/710 subfields a & b
by bugzilla-daemon＠liblime.com 06 Aug '09

06 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3163 Summary: With XSLT on, OPAC does not put any spacing between 110/710 subfields a & b Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: ASSIGNED Severity: enhancement Priority: P5 Component: OPAC AssignedTo: jwagner(a)ptfs.com ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 The OPAC does not place a space (or any delimiter) between subfields a and b of a 110/710 field if XSLT is on. I found a way to add the space by adding a <xsl:text> </xsl:text> line near the end of the MARC21slimUtils.xsl file. I'm including this in a patch file with other XSLT fixes. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3345] New: Return All items on patron detail does not initiate transfer of holds
by bugzilla-daemon＠liblime.com 05 Aug '09

05 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3345 Summary: Return All items on patron detail does not initiate transfer of holds Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- Example: Library 1 has a patron who has 5 books checked out (A, B, C, D, E). We have three branches in our system(1, 2, 3). A is an item from library 1 (the local branch) with no holds. B is an item from library 2, with no holds. C is an item from library 1 with a queued hold at library 2. D is an item from library 2 with queued holds at library 3. E is an item from library 1 with queued holds at library 1. When all items are returned via Return All: Item A is returned normally (ok) Item B is returned, but transfer is initiated without staff notification (problematic, but merely annoying) Item C is returned, but nothing happens. A transfer to fill the hold at Library 2 should be initiated, but is not. Koha checks it in and changes the current location to library 1. (very problematic) Item D similar to item C, the item is orphaned at Library 1. (very problematic) Item E needs more testing at this time, but wanted to get this bug submitted. Will add comment to elaborate. </example> Return ALL items on the patron detail page does not work well with holds/multiple branches. Proposed ways to fix this: RETURN ALL items presents each item in sequence to deal with individually (confirm/transfer/return home). Seems clunky. RETURN ALL items presents all items in an ajax-y way to click click click confirm/transfer/return home). Less clunky, but still... eh. Other ideas? I'm drawing a blank. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 2

[Bug 3249] New: LOST is not triggering replacement charge on checked out items
by bugzilla-daemon＠liblime.com 04 Aug '09

04 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3249 Summary: LOST is not triggering replacement charge on checked out items Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: mcoalwell(a)nekls.org CC: mcoalwell(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- Changing a checked-out item's status to LOST doesn't do anything but change its catalog status to LOST. Formerly, changing a checked-out item's status to LOST would immediately remove it from a patron's checkouts and show it as a lost item with replacement cost under the Fines tab). Some time recently this stopped working correctly. Koha Manual says: "If a replacement charge trigger is specified, the item [is] marked returned, removing it from the patron's account, and a charge is levied (even if it is $0) in accordance with the item replacement cost." -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 3211] New: cataloging value plugin forms should be valid XHTML
by bugzilla-daemon＠liblime.com 31 Jul '09

31 Jul '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3211 Summary: cataloging value plugin forms should be valid XHTML Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: galen.charlton(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- As a special subset of the general requirement that Koha's staff and public interfaces produce valid XHTML, most of the cataloging value plugins (e.g., for the MARC21 Leader and fixed fields) do not produce valid XHTML. The header for most cataloging plugin templates should be something like this:  <title>Koha &rsaquo; Cataloging &rsaquo; Leader builder</title>  </head> <body> <form name="f_pop" onsubmit="javascript:report()" action="#"> <input type="hidden" name="plugin_name" value="marc21_leader.pl" />\ and the footer  Note that as a result of including doc-head-close.inc, it will be possible to use the standard CSS to style the forms. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 3139] New: Patron Form Standardization
by bugzilla-daemon＠liblime.com 27 Jul '09

27 Jul '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3139 Summary: Patron Form Standardization Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nicole.engard(a)liblime.com Estimated Hours: 0.0 On the Patron form there are no standards when it comes to how we ask for contact info. In one area we ask for Address and Address 2 in another we ask for Address line 1 and Address line 2 and in another we only as for Address. These should all be standardizes to look the same - whatever way you want - but the same across the board. Another example of this is that we ask for Zipcode in 2 places and Zip/Post code in another - once again it should be standard across the board. At the top we ask for Surname and then First name - but under Alternate we ask for First name first and Surname second. Again - standardize. Under Contact I recommend putting Home & Cell phone on the same line and then putting Work and Fax numbers on the same line - removing 2 lines from the area but not going to wide across. Under Main Address I recommend putting Street Number & Street Type on the same row - also saving a bit of space. See the Add Patron form for all of these issues. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 3322] New: expandedSearchOption
by bugzilla-daemon＠liblime.com 24 Jul '09

24 Jul '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3322 Summary: expandedSearchOption Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P5 Component: OPAC AssignedTo: henridamien(a)koha-fr.org ReportedBy: laurence.lefaucheur(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- V3.00.02-final When expandedSearchOption is ON, in opac advanced search it is not possible to display the page with fewer options : when clicking Fewer options, the page goes to cgi-bin/koha/opac-search.pl?expanded_options=0, but the display is still expanded search options, and button Fewer options instead of More options. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3207] New: return before expiry set to yes...renewal date not affected
by bugzilla-daemon＠liblime.com 23 Jul '09

23 Jul '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3207 Summary: return before expiry set to yes...renewal date not affected Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: cookie.wolfrom(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- item renewed within time frame of patron card expiring, new due date for item will exceed the expiration date - -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3226] New: Extended characters aren't always properly displayed on resultat page when XSLT is on
by bugzilla-daemon＠liblime.com 15 Jul '09

15 Jul '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3226 Summary: Extended characters aren't always properly displayed on resultat page when XSLT is on Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: frederic(a)tamil.fr Estimated Hours: 0.0 Change sponsored?: --- When XSLT is on, in MARC21 and UNIMARC, on result page, some biblio records are not properly displayed. Extended characters (éèà...) are displayed as several bytes. The same biblio record which is badly displayed on result page is displayed properly on detail page. This bug occurs only for biblio records having several items, some with holding branch name containing extended characters, some only with ASCII branch name. This is obviously, one more time, an UTF8 mess! There is a difference between biblio record coming Zebra and the same coming from biblioitems.marcxml. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6