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

[Bug 6380] New: Z39.50 Cataloging Search needs a way to try search again, even if results are found
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '11

04 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6380 Bug #: 6380 Summary: Z39.50 Cataloging Search needs a way to try search again, even if results are found Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: wizzyrea(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Currently if you get results using the z30.50 cataloging search there is no handy way to return to search again. To test: do a search that will bring results scroll to bottom of the results table -- no options to go back to search. I propose we add a button to the bottom of the results to take you back to try another search. -- 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 6

[Bug 5131] New: XSS vulnerability in the OPAC search results interface
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '11

04 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5131 Summary: XSS vulnerability in the OPAC search results interface Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: critical 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 opac-search.pl: foreach my $sort (@sort_by) { $template->param($sort => 1); # FIXME: security hole. can set any TMPL_VAR here } This makes it pretty easy for someone to do things like inject arbitrary HTML and Javascript, and so steal the credentials of another user. This operation needs a whitelist of valid values that it checks against. -- 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 9

[Bug 5320] New: Estimate optionally next planned date for serials without periodicity
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '11

03 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5320 Summary: Estimate optionally next planned date for serials without periodicity Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: PATCH-Sent Component: Serials AssignedTo: m.de.rooy(a)rijksmuseum.nl ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 For periodicity Irregular, Unknown or "Without periodicity", it would be helpful if Koha could suggest a next planned date when receiving an issue based on the time interval between the last two receivals of this serial. This option is triggered by new local-use preference SerialEstimatePlannedDate. If this option exists and contains uppercase W for without periodicity, I for irregular or U for unknown, or a combination of those characters, the option is enabled for these particular periodicities. Behavior does not change for other periodicities. Implemented by some small changes in C4/Serials.pm, routine GetNextDate. Patch has been sent. -- 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 7

[Bug 5929] New: Use branch admin email for advance_notice.pl emails
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '11

02 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5929 Bug #: 5929 Summary: Use branch admin email for advance_notice.pl emails Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: shelley(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Instead of using the KohaAdminEmailAddress system preference, the PREDUE and DUE notices should send 'from' the email address configured in the branch management area, just like Overdues. KohaAdminEmailAddress should be a fallback if no address is configured for the branch. The branch selected should be the same as is selected for overdues. Work to be done: - Find the patch that added the functionality to overdues - Duplicate the functionality for DUE and PREDUE templates -- 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 12

[Bug 5053] New: singleBranchMode should control branch display all over
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '11

02 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5053 Summary: singleBranchMode should control branch display all over Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 When singleBranchMode is turned on all displays of multiple branches should be turned off: * Location on holdings in OPAC should only show shelving location * Location on holdings in Staff Client should only show shelving location * Branch selection pull downs should be hidden (everywhere) * Branch display in XSLT search results shouldn't appear There may be more I can add to this, but basic idea is that if there is one branch there is no reason to tell people what branch things are at. -- 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 6325] New: Bib detail - z39.50 button functionality should be under "Edit" menu.
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '11

02 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6325 Bug #: 6325 Summary: Bib detail - z39.50 button functionality should be under "Edit" menu. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: wizzyrea(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com The Z39.50 button on the bib detail screen does not work like any other instance of that button, and it can be confusing for users. Every other button that looks like that provides import functionality for new bib records. This one *overwrites* the current bib with the new, imported bib, and can cause cataloging errors if a staff member absent-mindedly uses it instead of one of the other similar-looking buttons. The functionality is very useful, as it allows staff to upgrade/replace a record with a better version VERY easily. I think we should keep it. I propose putting the button functionality under the "Edit" drop down, as "Replace record via z39.50" -- 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 5530] New: Biblibre enhancements to the admin scripts
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '11

02 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5530 Summary: Biblibre enhancements to the admin scripts Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 It improves admin module WUI. It add a jquery table sorter to various admin pages, framework editor, branches, item types, cities, authorized values, etc. -- 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 8

[Bug 5418] New: New itemBarcodeInputFilter for libsuite8 style barcodes
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '11

02 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5418 Summary: New itemBarcodeInputFilter for libsuite8 style barcodes Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: kmkale(a)anantcorp.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 In India a ILS product called Libsuite8 prints barcodes like b0007432. The barcode is not stored anywhere in libsuite8's database. Neither is barcode available in any of the reports generated by the software. The barcode 'b0007432' when scanned into the libsuite8 software is de-constructed like 'b' which is the itemtype i.e. Book in this instance, and '7432' which is the 'Accession Number'. The software then takes the logged in staff's branchcode and does a join on three tables 'Location', 'Media_Type', and 'Books' to retrieve the particular record from the database. There is no possibility of recreating the barcodes for insertion in Koha while doing a retrospective conversion, because of arbitrary length of the barcode string AND arbitrary number of zeros in the numeric part of the printed barcode AND the fact that there are no reports available from the software which contain barcodes AND the fact that the barcode is not stored in the database. But most importantly due to the simple fact that printed barcodes are duplicated among branches. -- 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 22

[Bug 6362] New: Fix MARC display in OPAC
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '11

01 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6362 Bug #: 6362 Summary: Fix MARC display in OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: ruth(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org One of the side-effects of Bug 5579 is that MARC and ISBD display loses items; a patch was submitted to fix this problem for ISBD, but one is needed for the MARC display, as well. -- 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 8

[Bug 5720] New: Fixing permissions for addbiblio.pl
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '11

01 Aug '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5720 Summary: Fixing permissions for addbiblio.pl Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Blocks: 5574 Estimated Hours: 0.0 -- 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