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

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '23

16 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |34036 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34036 [Bug 34036] Single receive doesn't reload data and order lines appears as pending -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34011] New: [DOCS] Add information on the option to place multiple bib-level holds
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '23

16 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34011 Bug ID: 34011 Summary: [DOCS] Add information on the option to place multiple bib-level holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org The feature to place multiple bib-level holds for a single patron that was added in bug 14695 doesn't seem to be mentioned in the manual. It would be helpful to have a note about it in Circulation/Holds/Placing holds in the staff interface, and in the page on Circulation and Fines rules, since the "Holds to place (count)" textbox only appears if the circulation rules allow more than 1, but fewer than Unlimited, holds per record for that patron type. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 30321] New: Order receive page dies if quantity received is more than 0
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '23

16 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30321 Bug ID: 30321 Summary: Order receive page dies if quantity received is more than 0 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Order receive page dies on error 500 if orders quantityreceived is more than 0. The error logs reads: "Template process failed: undef error - The method Koha::Item->count is not covered by tests!" This happens because in template orderreceive.tt we have "order.items.count" not "orders.items.count" as it should be. It seems that this error doesn't occur if template param edit is set as 1. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 32472] New: The method Koha::Item->count is not covered by tests
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '23

16 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32472 Bug ID: 32472 Summary: The method Koha::Item->count is not covered by tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org This is only possible under 21.11 (before bug Bug 29844 - Remove uses of wantarray in Koha::Objects) in templates where constructions like items.count etc are used on passed objects. Template Toolkit does evaluate these expressions in LIST context while we probably expected scalar context as when chaining in Perl. This particular crash comes from acqui/orderreceive.pl (and template): [% IF ( order.items.count ) %] In this case we should either use the Scalar plugin or - simply - use size here from TT itself. Note that this could be applied to master too since it is probably cheaper to stay in TT than call Koha::Objects/DBI here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 12442] Query... variables should be defined within loop in Search.pm
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '23

16 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12442 --- Comment #4 from David Cook <dcook(a)prosentient.com.au> --- Pretty sure this is still a problem. One of these days I need to sit down and have a big search review... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34017] New: Staff interface main page has double icons for search options
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '23

16 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34017 Bug ID: 34017 Summary: Staff interface main page has double icons for search options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you go to /cgi-bin/koha/mainpage.pl, there are double icons for "Advanced search" and "Item search". They're difficult to see but become more obvious when you mouse over the boxes on the screen. One of my librarians (who is one of the most observant people I've ever met) pointed this out to me this morning on a Koha 22.11. We all must have looked at this screen so many times... I don't know how we didn't notice it until now. It's still an issue in master as well. Patch incoming... -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 33064] New: Add a search option for licenses to top search bar
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33064 Bug ID: 33064 Summary: Add a search option for licenses to top search bar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com With bug 32728 we now switch to the correct search option when switching between different pages in the ERM module. For licenses we keep "Agreements", because there is no licenses search (yet). It would be nice if one could be added for consistency and for usability. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 33623] New: getAll not encoding URL params
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33623 Bug ID: 33623 Summary: getAll not encoding URL params Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 33445] New: Regression - Replacing authority via Z39.50 will not search for anything but the value from the existing authority
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33445 Bug ID: 33445 Summary: Regression - Replacing authority via Z39.50 will not search for anything but the value from the existing authority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, thibaud.guillot(a)biblibre.com Depends on: 29173 There are two steps to cataloguing/z3950_auth_search.pl - load it without op=do_search and it inserts the value from any params that match a form field name into the form and displays the form, or load it with op=do_search, and it searches for the values from params that match form field names and displays the results. Bug 29173 implemented prefilling the form for the case where you are coming from an authority detail view rather than an authority editor by looking up the existing authority record, and inserting values from it into the variables holding the input params. It does that in both the first step (overwriting changes you've made in the editor) and also in the do_search step, overwriting what you put in the search form with the data from the existing stored authority record. Steps to reproduce: 1. Find and edit any existing corporate name, personal name, subject or uniform title authority which will have results from the Z39.50 server you're going to search. For a usable ktd data and Library of Congress Names server example, use Smith, Bessie, 1894-1937. 2. In the editor, note what's in the main entry field's subfield a (Smith, Bessie) 3. Replace subfield a's contents with something different, like your own name 4. Click "Replace record via Z39.50/SRU search" 5. Note that rather than what you put in, the form field is filled with what the record originally had 6. Replace it with your name again, this time in the search form, select the server to search, and click Search 7. Note that the results are for what was originally in the record, not what you put in the form There are two cases where that makes replace via Z39.50 unusable: when you need something different than the original, like after a change in heading or when your existing record passed through an encoding error and you need to turn Gâomez, Hâector Carlos into Gómez, Héctor Carlos, and cases where just the subfield a is not enough to distinguish, like searching for Smith, John when you want Smith, John, Jr., -1853 who appears on page 39 of the results. Oh, and any name for UNIMARC, since subfield a is only the surname. A very good start to fixing this would be to revert bug 29173 from 22.11, 22.05, and 21.11, since this feature is now broken back to oldoldstable. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29173 [Bug 29173] Button "replace authority record via Z39/50/SRU" doesn't pre-fill -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 25379] New: HTML tags visible in Returns.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '23

15 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25379 Bug ID: 25379 Summary: HTML tags visible in Returns.pl Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 104375 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=104375&action=e… on returns.pl page With the introduction of this bug: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23409. ( Show circulation note and OPAC note with line feeds ), the ability to add HTML was included. However, when a patron note with HTML is seen during circulation (check-in)- the HTML tags are visible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26