August 2008 - Koha-bugs - lists.koha-community.org

[Bug 2537] New: inconsistent behavior when entering tag via add button or hitting return
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2537 Summary: inconsistent behavior when entering tag via add button or hitting return Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: galen.charlton(a)liblime.com QAContact: koha-bugs(a)lists.koha.org When entering a tag from the search results list or the a bib details page in the OPAC, what happens next depends on whether you hit return or click on the add button. Hit return: tag gets added, and browser redirected to opac-tags.pl. Click add button: tag gets added in place I think the desired behavior (at least when JavaScript is available) is to make hitting return add the tag in place, not redirect. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2536] New: AJAX tags entry does display results message in IE7
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2536 Summary: AJAX tags entry does display results message in IE7 Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P3 Component: OPAC AssignedTo: joe.atzberger(a)liblime.com ReportedBy: galen.charlton(a)liblime.com QAContact: koha-bugs(a)lists.koha.org When using IE7 on WinXP, attempting to enter a tag from the results list or the details page does not display the "tag added" message. Instead, IE7 reports a page error (in lower-left corner). The new tag does get saved. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2534] Table truncated
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2534 ------- Comment #1 from joe.atzberger(a)liblime.com 2008-08-19 07:48 ------- Created an attachment (id=423) --> (http://bugs.koha.org/cgi-bin/bugzilla/attachment.cgi?id=423&action=view) Screenshot of FF on Win32 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2503] process files from an offline circulation tool
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2503 Andrew.moore(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Priority|P3 |PATCH-Sent ------- Comment #2 from Andrew.moore(a)liblime.com 2008-08-19 07:43 ------- I submitted 9 patches (2 from Kyle) for this feature: http://markmail.org/message/fikr5trk6hxesaij ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2535] New: crashes in OPAC authorities search
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2535 Summary: crashes in OPAC authorities search Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: major Priority: P3 Component: OPAC AssignedTo: galen.charlton(a)liblime.com ReportedBy: galen.charlton(a)liblime.com QAContact: koha-bugs(a)lists.koha.org It is a bit too easy to make the OPAC authorities search ("browse by subject" AKA opac-authorities-home.pl) crash. A crash can be induced in at least two different ways: [1] Do any search with the order set to "none". Associated error in log is: [Tue Aug 19 09:25:41 2008] [error] [client 68.79.9.21] ZOOM error 20003 "can't set prefix query" (addinfo: "@or @attr 1=_ALLRECORDS @attr 2=103 '' ") from diag-set 'ZOOM', referer: http://gmc.dev.kohalibrary.com/cgi-bin/koha/opac-authorities-home.pl [Tue Aug 19 09:25:41 2008] [error] [client 68.79.9.21] Premature end of script headers: opac-authorities-home.pl, referer: http://gmc.dev.kohalibrary.com/cgi-bin/koha/opac-authorities-home.pl [2] Do a search where the search type is "Default" and more than one of the search boxes is filled in: [Tue Aug 19 09:26:35 2008] [error] [client 68.79.9.21] ZOOM error 20003 "can't set prefix query" (addinfo: "@or @attr 7=1 @attr 1=Heading 0 @attr 1=Heading @attr 5=1 @attr 4=6 "rere" @attr 1=Any @attr 5=1 @attr 4=6 "rere"") from diag-set 'ZOOM', referer: http://gmc.dev.kohalibrary.com/cgi-bin/koha/opac-authorities-home.pl [Tue Aug 19 09:26:35 2008] [error] [client 68.79.9.21] Premature end of script headers: opac-authorities-home.pl, referer: http://gmc.dev.kohalibrary.com/cgi-bin/koha/opac-authorities-home.pl These crashes may also affect the staff authorities search. C4::AuthoritiesMarc::SearchAuthorities() needs to catch all ZOOM exceptions. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2534] New: Table truncated
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2534 Summary: Table truncated Product: Koha Version: HEAD Platform: PC URL: /cgi-bin/koha/cataloguing/additem.pl OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Cataloging AssignedTo: galen.charlton(a)liblime.com ReportedBy: joe.atzberger(a)liblime.com QAContact: koha-bugs(a)lists.koha.org Client reports (complete with screenshot) that the addition of new column "Source of classification or shelving scheme" forces the table to be truncated on the right side (including part of the "Date last borrowed" column). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2533] New: User record change requests in OPAC
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2533 Summary: User record change requests in OPAC Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: beverly.church(a)liblime.com QAContact: koha-bugs(a)lists.koha.org CC: rch(a)liblime.com User change requests in OPAC are sent to the email address in the KohaAdminEmailAddress. Is it possible to change this so that these requests are to the email address in the location record? Currently user change requests and purchase suggestions are both sent to the email address in the KohaAdminEmailAddress preference. This was submitted on behalf of a consortium client. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2532] Patron-requested holds limited to one item per bib.
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2532 ------- Comment #1 from oleonard(a)myacpl.org 2008-08-19 05:50 ------- There are other situations besides serials where multiple items might be reserved: multi-volume sets like encyclopedias or multi-part video sets (NPL's bugbear: http://search.athenscounty.lib.oh.us/cgi-bin/koha/opac-detail.pl?bib=93738) It is also useful for staff to be able to reserve multiple items. Catalogers may need to retrieve all copies of a particular item for relabeling. Staff may wish to reserve multiple copies of a book for use in a book discussion group. It would be great to give staff users that option. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2532] New: Patron-requested holds limited to one item per bib.
by bugzilla-daemon＠pippin.metavore.com 19 Aug '08

19 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2532 Summary: Patron-requested holds limited to one item per bib. Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: rch(a)liblime.com QAContact: koha-bugs(a)lists.koha.org The current holds implementation limits a hold to be either title-level or item-level, and only one outstanding hold may be placed at a time. This is a significant shortcoming, especially for serial records, where a patron may wish to request several issues. There should be some way to distinguish whether all item records attached to a bib record are equivalent in the sense of fulfilling a hold request. I feel at this stage that using the biblio.serial flag should be sufficient for this. ( However, note that the existence of a series title can trigger the serial flag. I think that is a behavior added by BibLibre, and should be addressed). If there is such a flag, then we can allow multiple item-level requests on a single bib, and, on fulfillment, cancel all other hold requests if items are determined to be equivalent. There is some code for this tucked away in the dev_week branch, though I imagine at this point the holds code will need to be refactored such that that code is irrelevant. In short, this enhancement request is for allowance of multiple concurrent item-level, but a precursor I think is the stated interpretation of the biblio.serial flag as indicating that multiple concurrent item-level holds are _not_ equivalent, where in all other cases they are. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2531] New: Cannot delete private shelf.
by bugzilla-daemon＠pippin.metavore.com 18 Aug '08

18 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2531 Summary: Cannot delete private shelf. Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: major Priority: P3 Component: Virtual Shelves AssignedTo: jmf(a)liblime.com ReportedBy: joe.atzberger(a)liblime.com QAContact: koha-bugs(a)lists.koha.org Can't seem to delete private shelves, even if empty and user is owner. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0