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

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

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11300 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #163946|0 |1 is obsolete| | --- Comment #72 from Hammat wele <hammat.wele(a)inlibro.com> --- Created attachment 171304 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=171304&action=e… Bug 11300: Add a new authority linker which searches for authority links on a Z39.50 server. This patch adds a Z39.50 Linker which searches for authority links on a remote server. If a matching authority is found, it's imported in the local database for linking with the current biblio record. If no matching authority was found on the remote server, the Linker falls back to a local authority search. Configuration : * The option "Z39.50 Server" is added to the LinkerModule preference. You must choose this to use the new Linker. * The preference LinkerZ3950Server is required and specifies which server to use for linking. It must contain the "name" of the server, as defined in the z3950servers table. * You can set the "local_first" option in the LinkerOptions preference to force the Linker to search for authorities in the local database first. If no local authority match was found, the Linker falls back to a remote Z39.50 search. Sponsored-by: CCSR ( http://www.ccsr.qc.ca ) -- You are receiving this mail because: You are watching all bug changes.

1 0

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

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11300 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #163947|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12133] Guarantor requirements when registering a patron
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12133 Nick Clemens (kidclamp) <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37892 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37892 [Bug 37892] Patron category 'can be a guarantee' means that same category cannot be a guarantor -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25621] New: Some tests in t/DateUtils.t fail when timezone is not UTC
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25621 Bug ID: 25621 Summary: Some tests in t/DateUtils.t fail when timezone is not UTC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce: 1. Verify that TZ environment variable is not defined 2. Verify that $KOHA_CONF does not contain <timezone> 3. Run `date` to verify that you have a local time different than UTC 4. prove t/DateUtils.t Expected output: % prove t/DateUtils.t t/DateUtils.t .. 1/76 # Failed test 'dt_from_string handles seconds with 1 decimal place' # at t/DateUtils.t line 130. # got: '1325447940' # expected: '1325462340' # Failed test 'dt_from_string handles seconds with 2 decimal places' # at t/DateUtils.t line 133. # got: '1325447940' # expected: '1325462340' # Failed test 'dt_from_string handles seconds with 3 decimal places' # at t/DateUtils.t line 136. # got: '1325447999' # expected: '1325462399' # Failed test 'dt_from_string handles seconds with 3 decimal places and a timezone' # at t/DateUtils.t line 139. # got: '1325447999' # expected: '1325462399' # Looks like you failed 4 tests of 76. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 30540] New: Double processing invalid dates can lead to ISE
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30540 Bug ID: 30540 Summary: Double processing invalid dates can lead to ISE Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In the KohaDates filter we process our passed date using dt_from_string before passing it to output_pref. dt_from_string handles bad dates in an eval block, falling back to assigning a floating timezone. However, in the subsequent call to output_pref we try to set the timezone a second time and this time it is not in an eval and so will throw an internal server error for such dates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 35666] New: Make it possible to cancel the transfer of the item
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35666 Bug ID: 35666 Summary: Make it possible to cancel the transfer of the item Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kati.sillgren(a)porvoo.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Record information page (catalogue/detail.pl): make it possible to cancel the transfer of the item when it is not in transit due to reservation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 21559] New: Rules for automatic framework codes
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21559 Bug ID: 21559 Summary: Rules for automatic framework codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Allow setting rules in a system preference, what framework code should be automatically set for biblio, based on the MARC record fields. Does not affect anything if the MarcToFrameworkcodeAutoconvert system preference rules aren't used. The "Default" framework is always overridden, if the rules match, but some other framework chosen by you is always used. Explanation of the rule format: ------------------------------- The syspref is YAML, with a specific format: - <field> <value>: <frameworkcode> If the <field> in the record contains <value>, the <frameworkcode> is used for the record. <field> is one of: "xxx" (field xxx in the MARC record) "xxx/yy" (field xxx, character location yy) "xxx/yy-zz" (field xxx, character locations yy-zz) "xxx$v" (field xxx, subfield v) Fields can be combined with plus-sign, then the field values have plus-sign between them. The field-rules are checked in order from top to bottom, and the first rule with a matching value is used. If the (sub)field has been repeated in the MARC record, only the first matching (sub)field is checked. If none of the rules match, the framework code is not changed. Example: - 008/35-37 + 000/06: fin+a: BKSFIN - 000/06: a: BKS c: MU e: MP This would make record with 000/06 = "a" AND 008/35-37 = "fin" use the BKSFIN framework, and any other record with 000/06 = "a" use BKS, 000/06 = "c" would be MU, and 000/06 = "e" would give MP -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 37161] New: After deleting a tag in a MARC framework, template doesn't do the [% IF ( delete_confirmed ) %] stuff
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37161 Bug ID: 37161 Summary: After deleting a tag in a MARC framework, template doesn't do the [% IF ( delete_confirmed ) %] stuff Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: emily.lamancusa(a)montgomerycountymd.gov In older versions (I tested in 23.05.11 since I had it handy), when you edit a MARC framework and delete a tag, you get a page saying "Tag deleted" with an OK button, and clicking the button reloads the framework you were in (though not exactly the way it was originally inteded to, since it's supposed to reload with a search for the tagnumber, so you wind up in the same place you were). In main, you don't get the "Tag deleted", which is inside an [% IF ( delete_confirmed ) %]. I don't see what magic was ever setting delete_confirmed, unless it was set by that being the name of the $op back before it became cud-delete_confirmed. https://git.koha-community.org/Koha-community/Koha/src/commit/582d6916c9a4e… explicitly sets it, but I don't see where anything else does, and if the magic was coming from the $op, then there's a whole bunch more things that need to be fixed to set it. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 37127] New: Authorized value select not working on authority forms.
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37127 Bug ID: 37127 Summary: Authorized value select not working on authority forms. Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kdask(a)altsol.gr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When connecting an authorized value on a subfield on Authority Type framework configuration (Example: 040$b - Authorized value: LANG) the Select widget (Select2?) on the cataloging form (Edit/New) is not working. This seems to happen for any connection on any authorized values/subfields only on authorities cataloging. Tried creating new authorized value category etc, but the behavior is the same. Thanks -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 37165] New: Can't edit frequencies due to stray cud- in modify op
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '24

11 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37165 Bug ID: 37165 Summary: Can't edit frequencies due to stray cud- in modify op Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Serials Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 36192 serials/subscription-frequencies.pl has two modify ops: a POST with cud-savemod changes the frequency, and a GET with modify loads the editing form, except that was changed to cud-modify when it shouldn't have been. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes.

1 13