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

[Bug 31705] New: Option for ILL "Manage Request" button to appear on Left of the screen to improve accessibility
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31705 Bug ID: 31705 Summary: Option for ILL "Manage Request" button to appear on Left of the screen to improve accessibility Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.evans(a)ukhsa.gov.uk To improve accessibility and reduce excessive scrolling we would like an option for the "Manage Request" button on the list of ILL requests to appear on the left of the screen. It currently displays on the far right of the screen and normally requires scrolling beyond the columns displaying in the table for each request to be processed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 22714] New: ILL table population call might benefit from being inside the datatable
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22714 Bug ID: 22714 Summary: ILL table population call might benefit from being inside the datatable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Target Milestone: --- As pointed out by Owen (http://irc.koha-community.org/koha/2019-04-16#i_2134071) the ILL table doesn't display any "loading" message while the API call is in progress. It would be a better experience for the user if it did. We should investigate populating the table from within the datatable object, we will then get the benefit of then in built loading message. If not, we could always add a message manually. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 32563] New: Reservedate becomes expirationdate in some cases
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32563 Bug ID: 32563 Summary: Reservedate becomes expirationdate in some cases Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Database fields DATE/DATETIME/TIMESTAMP in DBIX-Class are automatically available as DateTime objects that we can perform operations on (for example add an interval). But there is a feature: addition or subtraction operations (->add in this case) change the main object in-place and return the new value as the result of the expression. Because of this feature, due to the fact that the address to ->reserve date was passed to the ->add function, ->reservedate itself was changed, and then the result was assigned to ->expirationdate. This implicit feature resulted in an error when both dates after the given operation were the same in the future. Solution: To not change the original DateTime object, it must be cloned: https://metacpan.org/pod/DateTime#$dt-%3Eclone , accordingly, the changes will be made in a temporary copy, and a new value will be assigned to expirationdate, and the original reservedate will not change. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 32567] New: Update plugin unimarc_field_110.pl 'Script of title' and 'Translitteration code'
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32567 Bug ID: 32567 Summary: Update plugin unimarc_field_110.pl 'Script of title' and 'Translitteration code' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Update value builder for unimarc_field_110 with some values -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 31650] New: We should publish our coding guidelines more openly
by bugzilla-daemon＠bugs.koha-community.org 05 May '23

05 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31650 Bug ID: 31650 Summary: We should publish our coding guidelines more openly Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com Our coding guidelines are currently hidden deep in th wiki.. to encourage more reference to them, we could publish them more openly as their own mini-site linked directly from the website.. more akin to our manual and API docs sites. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 32795] New: ILLHiddenRequestStatuses system preference description is wrong
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32795 Bug ID: 32795 Summary: ILLHiddenRequestStatuses system preference description is wrong Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de Depends on: 28641 Currently, the ILLHiddenRequestStatuses sys preference reads: "... The request codes can be found in the ILLSTATUS authorized value category." But, the request status codes actually come from status_graph of their respective backend, or alternatively from core Koha::Illrequest, not from ILLSTATUS. ILLSTATUS AV is only used for a request's status_alias, which is an alternate list of statuses that is only used to give the staff member the ability of adding their own statuses by editing a request. On top of that, bug 28641 refers to the fact that the code that is checking this system preference doesn't even consider the requests' status_alias, only the actual status coming status_graph in code. I think this label should be updated to reflect that it may use both the status codes from installed ILL backends and the values from ILLSTATUS, once 28641 is fixed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28641 [Bug 28641] ILLHiddenRequestStatuses does not consider custom statuses -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 30920] New: Add caching to C4::Biblio::GetAuthorisedValueDesc
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30920 Bug ID: 30920 Summary: Add caching to C4::Biblio::GetAuthorisedValueDesc 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Whilst working on bug 30848 inspired by bug 28371 it became apparent we're using this function a huge amount inside of various loops. We should cache the data to allow for performance improvements. The patches submitted here have been pulled out of the submission for bug 30848 as they have a much wider effect and need proper independent testing. In benchmarking I found that enabling the caching in the way here gave me very significant performance improvements as compared to bug 28371. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 66

[Bug 31493] New: Circulation.t fails if "RenewalPeriodBase" is set as "the current date"
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31493 Bug ID: 31493 Summary: Circulation.t fails if "RenewalPeriodBase" is set as "the current date" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Like in bug 26405 Circulation.t fails on the following error: t/db_dependent/Circulation.t .. 15/63 # Failed test 'AddRenewal left both fines' # at t/db_dependent/Circulation.t line 770. # got: '1' # expected: '2' # Looks like you planned 105 tests but ran 30. # Looks like you failed 1 test of 30 run. t/db_dependent/Circulation.t .. 17/63 # Failed test 'CanBookBeRenewed tests' # at t/db_dependent/Circulation.t line 1538. Can't call method "status" on an undefined value at t/db_dependent/Circulation.t line 772. Apparently this is happens when syspref "RenewalPeriodBase" is set as "the current date". -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 31676] New: Fix db_dependent/Circulation.t tests
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31676 Bug ID: 31676 Summary: Fix db_dependent/Circulation.t tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A lot of tests in db_dependent/Circulation.t are currently failing, many seems to have done so for quite a while so it's a bit puzzling how this has gone under radar for such a long time. If any of the changes are unclear I'm happy to expand more on the different addressed issues. A short summary of the changes: - The patron attribute autorenew_checkouts was added a while ago, patrons for some tests needed this set to preserve previous behavior - OverduesBlockRenewing-test relied on a state that was mutated by new tests, these have been moved to a place where the state is as was before this regression. - The test "AddRenewal left both fines" broke when account line statuses where refactored (probably), there should be one one fine - Fixed a test which expects 'auto_to_soon' error. CanBookBeRenewed will not return this status unless the $cron parameter is set to true - "Incremented fee tests" builds an item with missing "library" parameter since treating the library object as a hashref. This cases a circulation-rule not match and serveral tests fail as a result. - The "AddIssue records staff who checked out item if appropriate" subtest treats some objects as hashrefs when retrieving properties, and also checks the wrong issue objects in the last test. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 32916] New: [Bug 30280 follow-up] Problems in linking authorities to biblio fields (MARC 21)
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32916 Bug ID: 32916 Summary: [Bug 30280 follow-up] Problems in linking authorities to biblio fields (MARC 21) Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frank.hansen(a)ub.lu.se, katrin.fischer(a)bsz-bw.de I encounter two problems connected to recent changes in the Linker module: 1. Problem with thesaurus in biblio fields different than 6XX (Zebra and ES) a) The search for a needed authority record (in C4::Heading::_search) is made now not only with the search form derived from controlled field content, but also with the second operand – the thesaurus. The second operand is added when $self->{thesaurus} is defined. And at the current for MARC 21 it is always defined (C4::Heading::MARC21::parse_heading returns the right thesaurus symbol for 6XX fields and ‘lcsh’ for the rest, e.g. 1XX, 7XX, 8XX). b) So, if $self->{thesaurus} ide defined (= always), the thesaurus operand in authority search is determined by examining the second indicator of the field in the bibliographic record. (I leave apart the discussion of why it is taken from the internal structure of the MARC::Field object while $self->{field}->indicator(‘2’) would be the correct way). But the second indicator makes sense – in terms of thesaurus – only for fields 6XX. For other controlled fields it is either undefined or has completely different meaning (e.g. in 700, 710, 711, 730, 830 etc.). The c) So, in C4::Heading::_search we should consider the thesaurus operand only for 6XX fields. This could be done either by checking $self->{field}->tag in C4::Heading::_search or by not defining $self->{thesaurus} in C4::Heading::MARC21::parse_heading for fields != 6XX. 2. Problem with thesauri in Zebra searches a) While preparing Zebra indexes for authorities (authority-zebra-indexdefs.xsl), the 008/11 byte or authority record is transformed from one character code to the symbol (a => lcsh, b => lcac, etc.). b) But in C4::Heading::_search the thesaurus operand is formulated as one character code conforming to the auth 008/11 convention. As a consequence, no results are returned (unless by accident). c) A possible solution could be removing the transformation (authority-zebra-indexdefs.xsl, koha-indexdefs-to-zebra.xsl) while generating Zebra index or refactoring the thesaurus fragment in C4::Heading::_search to reflect this duality in recording information in indexes (Zebra vs. ES). Could anybody confirm that the problems occur in other installations? Cheers! - Janusz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19