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

[Bug 21996] SPAM
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '24

22 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21996 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |34663 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34663 [Bug 34663] Errors in UNIMARC default framework -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35383] New: Dragging and dropping subfield of repided tags doesn't work.
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '24

22 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35383 Bug ID: 35383 Summary: Dragging and dropping subfield of repided tags doesn't work. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Cataloging Assignee: slavashishkin(a)gmail.com Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This does not work when editing an existing record or when creating a new record in basic editor mode. To test: 1. Open any Biblio and edit that record. (select "Edit record" from the "Edit" drop-down menu). 2. Repeat any tag that may be repeated and has more than one subfield (e.g. 050 or 082) (click "Repeat this tag") 3. that when you try dragging a subfield of the new repeated tag, the entire new tag moves. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 34219] New: getAll not allowing additional parameters
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '24

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34219 Bug ID: 34219 Summary: getAll not allowing additional parameters Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal 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 It's not possible to pass additional URL parameters. We need it at least for bug 32474. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 32468] New: Vendors select only allows selecting from first 20 vendors by default
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '24

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32468 Bug ID: 32468 Summary: Vendors select only allows selecting from first 20 vendors by default 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: martin.renvoize(a)ptfs-europe.com 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 Depends on: 32030 It looks like we forgot about API paging when implementing the vendors select box on ERM.. as such, by default, we can only access the first 20 vendors created on the system. Is there perhaps a Select2 style vue component we could lean on for this.. both to improve consistency and to resolve this paging issue too.? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 25

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

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #24 from Lisette Scheer <lisette.scheer(a)bywatersolutions.com> --- (In reply to Martin Renvoize from comment #23) > As for the --- digest thing, I feel like the logic for that one is backwards > and strange.. we should be generating the notice all in one hit at a later > point in time rather than queuing a notice and then munging extra stuff into > it after the fact at various times. The --- digest thing also doesn't make much sense to me. With putting it together at one point in time, would that mean that say for hold notices when notices send every hour that before that happened it would build and check for the patron any waiting holds that had been set to waiting since the last one? Or perhaps we could set some sort of flag when the hold is trapped that gets cleared when the notice is sent? -- You are receiving this mail because: You are watching all bug changes.

1 0

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

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #23 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- It's not just the custom --- handling if digests that need thought.. there is also a customer loop syntax in our <<>> style I believe.. that and the special handling for attributes code conversion stuff that I'm already also working on. As for the --- digest thing, I feel like the logic for that one is backwards and strange.. we should be generating the notice all in one hit at a later point in time rather than queuing a notice and then munging extra stuff into it after the fact at various times. Food for thought. Happy to grab a call some time to discuss the things I've been contemplating around this area for some time now if it helps -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28108] New: LetterLog/Acquistions/Claims: Logging filters are broken
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '24

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28108 Bug ID: 28108 Summary: LetterLog/Acquistions/Claims: Logging filters are broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We stripped out the fix for claims/acquisitions/letter logging filtering from bug 14233. I'll attach a copy of the code here for prosperity. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 36389] New: Acquisition order logging does not depend on AcquisitionLog system preference
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '24

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36389 Bug ID: 36389 Summary: Acquisition order logging does not depend on AcquisitionLog system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since Bug 28108 logging acquisition order is in module 'ACQUISITIONS'. So logging must depend on AcquisitionLog system preference. Currently it depends on ClaimsLog system preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

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

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #22 from Emily Lamancusa <emily.lamancusa(a)montgomerycountymd.gov> --- Hmmm, I hadn't actually thought about replacing the digest syntax... [% FOREACH %] doesn't work for digest-building, because the ---- marker doesn't represent a piece of logic or substitution internal to one notice, but rather it's metadata that tells the code how to parse and store the prepared message so that a new message can be combined properly with an old message after the fact, without duplicating the parts that should be the same: > sub _metadata { > my ($letter) = @_; > if ($letter->{content} =~ /----/) { > my ($header, $body, $footer) = split(/----\r?\n?/, $letter->{content}); > return { > header => $header, > body => [$body], > footer => $footer, > }; > } else { > return { > header => '', > body => [$letter->{content}], > footer => '', > }; > } > } Is that something we can (usefully) replace with Template Toolkit? (this may also be a "next step" question, to avoid making the perfect the enemy of the good) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36387] New: debian/scripts: daemon --user should contain colon instead of period
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '24

21 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36387 Bug ID: 36387 Summary: debian/scripts: daemon --user should contain colon instead of period Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial 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 Documentation says: -u, --user=user[:group] - Run the client as user[:group] Koha uses a period. So thats formally incorrect (but seems to work). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2