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

[Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |33822 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33822 [Bug 33822] Update variable picker to insert TT variables -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32892] New: Email template used when generating DISCHARGE PDF
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32892 Bug ID: 32892 Summary: Email template used when generating DISCHARGE PDF Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The generated PDF discharge letter always picks the 'email' transport by default. This means users expecting to define a 'print' version of the discharge notice get confgused and/or wrong results. This was highlighted by bug 14251, which fixed styling the PDF with CSS, which is only picked if the 'email' transport letter is used. It is trivial to see this doesn't work as no transport is passed to GetPreparedLetter, which then defaults to 'email'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 14251] Allow use of CSS in discharge letter
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14251 Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED CC| |caroline.cyr-la-rose@inlibr | |o.com --- Comment #39 from Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> --- Seems like back end stuff. I still reviewed the discharge sections in the manual to at least update the screenshots... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14250] Can generate discharge for patrons with fines
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14250 --- Comment #5 from Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> --- Still valid in master (22.12.00.048) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #7 from Lucas Gass <lucas(a)bywatersolutions.com> --- I would love to see this get back on the roadmap, perhaps for 23.11. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33579] New: Typo: record record
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33579 Bug ID: 33579 Summary: Typo: record record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org $ grep -rn "record record" * koha-tmpl/intranet-tmpl/prog/en/modules/admin/background_jobs.tt:184: '_str': _("Batch bibliographic record record deletion") -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 33303] New: Performance issues/timeouts when using more_subfields_xml in item search
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33303 Bug ID: 33303 Summary: Performance issues/timeouts when using more_subfields_xml in item search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using items from more_subfields_xml in item search there are performance issues, especially on bigger data sets. more_subfields_xml is an XML blob type column in the items table, that will be used when you create additional item fields not mapped to another column in the items table. Not sure if something could be done here, but maybe there is something we could do to optimize processing? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 11300] Add a new authority linker which searches for authority links on a Z39.50 server.
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11300 --- Comment #59 from Phil Ringnalda <phil(a)chetcolibrary.org> --- I wasn't asking for a weird enhancement I just thought of, I was describing the behavior of an authority linker. Order matters, Dogs -- Food and Food -- Dogs are not the same headings. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33816] New: Holds API errors not easily machine-readable
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33816 Bug ID: 33816 Summary: Holds API errors not easily machine-readable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au CC: tomascohen(a)gmail.com At the moment, if you place a hold via the Holds API and there are too many holds for the record, you get the following response: {"error":"Hold cannot be placed. Reason: tooManyHoldsForThisRecord"} That's a message that is meant for a human developer. It's not showable to a human audience, and it's not easily parsed by a machine. It would be good to have a human readable message for troubleshooting, but the core error code should just be "tooManyHoldsForThisRecord", as a machine can take that string and work with it as a code. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15567] Update API to allow multiple holds for the same record
by bugzilla-daemon＠bugs.koha-community.org 24 May '23

24 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15567 --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #6) > Surely it would make sense to just take multiple items in as input and then > run it through a loop and record the results. I mean I've created my own API endpoint in a different system which takes data for multiple items and does exactly that, so that 1 API call on that system can place holds for multiple items at the same time. (It's just the backend API call to the Koha that has to be done X times.) -- You are receiving this mail because: You are watching all bug changes.

1 0