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

[Bug 28645] New: write off fine on selected items does not pay against those lines
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '21

03 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28645 Bug ID: 28645 Summary: write off fine on selected items does not pay against those lines Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Selecting outstanding fines which do not happen to be the earliest in the accountlines table for the borrower will result in the earliest fines being written off instead of the ones selected. 1. In a list of 4 fines for a borrower, select tick box on one which was not the first to be accrued. 2. Click the write off button at the bottom of the screen. 3. Note the payment is shown against the earliest accrued item instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 26356] New: Search by first and last name takes a long time
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '21

03 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26356 Bug ID: 26356 Summary: Search by first and last name takes a long time Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: jcautomatizacion(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 109546 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109546&action=e… Search by first and last name takes a long time Currently when performing a search by user in Koha using first and last name, the system takes more than 22 minutes to execute the search, while the identification number does not delay, what can this inconvenience be?. Attachment dispatch script reported that performs search and delay. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 24532] New: Some account types are converted to debits when they shouldn't be
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '21

03 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24532 Bug ID: 24532 Summary: Some account types are converted to debits when they shouldn't be Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 23049 converts some credit types to debit types The logic seems to be: 1 - Get all unique types where the accountline is a debit 2 - Convert all lines with these types to have debit codes But in step 1 if we have any type 'Pay' or 'W' for example, where the amount is greater than 0 (pathological credits which have debit amounts) then 'Pay' is added as a debit type and all 'Pay' lines get that as a debit code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 29132] New: API access denied after update to 19.11.22 due to not executed atomicupdate for api keys
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '21

02 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29132 Bug ID: 29132 Summary: API access denied after update to 19.11.22 due to not executed atomicupdate for api keys Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.borkowski(a)kau.se After updating from 19.11.21 to 19.11.22, API access to our Koha instance failed. The reason was that the installer/data/mysql/atomicupdate/bug_28772_api_keys.pl was not executed, likely due to the fact that installer/data/mysql/updatedatabase.pl only executes files that end in .perl or .sql, while the new one ends in .pl. Manually executing the equivalent code (hashing the API-keys) fixes the problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 29564] New: Use List::MoreUtils so SIP U16/Xenial does not break
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '21

02 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29564 Bug ID: 29564 Summary: Use List::MoreUtils so SIP U16/Xenial does not break Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org patch to come... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 29072] New: Move reference route /cities spec to YAML
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '21

02 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29072 Bug ID: 29072 Summary: Move reference route /cities spec to YAML Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com We have been adding routes in YAML format, which provides an easy path for adding Markdown documentation. The reference route should be migrated. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 23013] New: Upgrade DataTables in the staff client
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '21

02 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23013 Bug ID: 23013 Summary: Upgrade DataTables in the staff client 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I would like to upgrade the DataTables plugin used in the staff client. This process will include: - A new concatenated, minified version of the DataTables components. - Removal of the custom "four_button" pagination configuration in favor of the built-in "full" pagination type. - Update style of pagination bars, including some additions to improve responsive behavior. Table-specific CSS, including our DataTables CSS, is now in a separate file, "_tables.scss" which compiled into staff-global.css. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 28338] New: Avoid validating holdability along with a specific pickup location
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '21

02 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28338 Bug ID: 28338 Summary: Avoid validating holdability along with a specific pickup location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Several bugs tried to address this question: when calling CanItemBeReserved, what pickup location parameter should be passed? And we've been going back and forth between userenv, reservescontrolbranch, etc. And there are two open bugs related to the area. Truth is, CanItemBeReserved is being passed a branchcode, but what we really be doing, is checking if the item can be reserved (at any pickup location) and provide a way for item-level holds to have a valid pickup location selected by staff members. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 29445] New: Checking replace cover image should actually replace cover image
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '21

01 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29445 Bug ID: 29445 Summary: Checking replace cover image should actually replace cover image Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To duplicate: In this scenario, the Coce image service pulls the incorrect cover image. 1. System setting AllowMultipleCovers is set to allow and CoceProviders is set to all. 2. Upload a new image cover and select replace cover image. 3. Check the normal view in the staff client and see that the new image displays as the default image and the Coce image displays as a second hidden image that can be selected to view. 4. Check OPAC view, both images continue to be displayed. Repeat these steps but set AllowMultipleCovers to not allow. Both images continue to be displayed. I would have expected that by checking replace cover image that the cover image is actually replaced. Instead it looks like ticking that box sort of makes the image the first image that is displayed but doesn't actually replace. As for the setting AllowMultiple Covers - this needs clarification. Ideally a bib record should allow multiple images but with the option to select the default cover image and the ability to not show the Coce image if it is not correct. This may be related to ticket 29359 and 26933. It looks like additional cover image tools or preferences are needed. Selecting a default image, actually replacing a cover image in place of the Coce image, deleting an image, selecting how many images show, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 29447] New: authority that begins with a number isn't found in tag editor search
by bugzilla-daemon＠bugs.koha-community.org 01 Dec '21

01 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29447 Bug ID: 29447 Summary: authority that begins with a number isn't found in tag editor search Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate : 1. Have an authority that starts with a number. Exemple : uniform title, 1000 feuilles 2. Create or modify a bibliographic record 3. In the tag editor (wether it's in tag 130, 630, 730, 830 the result is the same), search for the authority 1000 feuilles. The result is the same with any of the field (Search main heading ($a) only, Search main heading, Search all headings or Search entire record) 4. We obtain No results found. 5. Erase the number 1000 and keep feuilles only, we obtain the authority 1000 feuilles. Same goes with other authorities, such as meeting name, person name or corporate name, not only uniform title. When we search in Authorities, we can find the authority with any of the indexes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5