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

[Bug 21043] New: Add routes to add debits to a patron's account
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21043 Bug ID: 21043 Summary: Add routes to add debits to a patron's account 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: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 --- Comment #2 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- In the case of the CLA plugin, we add a button that triggers a call to `plugins/run.pl?class=[% CLASS %]&method=...` Anything that follows that pattern to trigger a plugin method to run, will require some more involved permissions. In the CLA case, I think I'd like to generally modernise the approach so we don't need to call the run method.. so I'm not sure what wider effects this may have on other plugins. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28592] New: ISE after paying through opac payment plugin
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28592 Bug ID: 28592 Summary: ISE after paying through opac payment plugin Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org After upgrading to 20.11.06, we have a problem with using the koha-plugin-dibs-payments plugin for online payments: https://github.com/Libriotech/koha-plugin-dibs-payments After authenticating with the remote service the user is redirected back to <opac>/cgi-bin/koha/opac-account-pay-return.pl However, this page presents a login form, and the user is forced to log in. It looks like this happens because the value of the CGISESSID cookie is changed somewhere along the way. Or does it change because the login screen is presented? Not sure of what is cause and what is effect here. After logging in, the user is redirected (with a 303 status) to the same URL, but this time all the parameters that were POSTed the first time around are now included in the URL as one kind of weird GET parameter (note the semicolons between parameters): ?orderid=123;payment_method=Koha%3A%3APlugin%3A%3ACom%3A%3ABibLibre%3A%3ADIBSPayments;transact=123;authkey=abc etc The payment is recorded in the accountlines table, but koha_plugin_com_biblibre_dibspayments_dibs_transactions.accountline_id is left empty. As far as I can tell, checkauth is only used in two places in the opac, opac-account-pay-return.pl and opac-ratings.pl: $ sudo grep -rn "checkauth" /usr/share/koha/opac/cgi-bin/opac/opac-* /usr/share/koha/opac/cgi-bin/opac/opac-account-pay-return.pl:29:my ( $userid, $cookie, $sessionID, $flags ) = checkauth( $cgi, 0, {}, 'opac' ); /usr/share/koha/opac/cgi-bin/opac/opac-messaging.pl:24:use C4::Auth; # checkauth, getborrowernumber. /usr/share/koha/opac/cgi-bin/opac/opac-passwd.pl:25:use C4::Auth; # checkauth, getborrowernumber. /usr/share/koha/opac/cgi-bin/opac/opac-privacy.pl:22:use C4::Auth; # checkauth, getborrowernumber. /usr/share/koha/opac/cgi-bin/opac/opac-ratings.pl:40:my ($userid, $cookie, $sessionID) = checkauth( $query, 0, {}, 'opac' ); /usr/share/koha/opac/cgi-bin/opac/opac-reserve.pl:24:use C4::Auth; # checkauth, getborrowernumber. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 28448] New: Record with too many items is not shown in results
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28448 Bug ID: 28448 Summary: Record with too many items is not shown in results Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: b.pastern4k(a)gmail.com In our library there are some records (newspapers) that have lots of items, some have more than a thousand items. It seems that if there's more than a thousand items per one location then this record is not shown in any searches, only way to access it is to know biblionumber and insert it into URL. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 28979] New: Cronjob references in system preference descriptions don't make sense for most installations
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28979 Bug ID: 28979 Summary: Cronjob references in system preference descriptions don't make sense for most installations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The references added in bug 21158 are path references from a git/dev installation. Most production installations are probably from packages or source installs which will have a path like "../bin/cronjobs/<script>" where they're relative to the application root/installation base. At the moment they say "misc/cronjobs/<script>". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 27141] New: QueryWeightFields should be 0 on new installs since QueryAutoTruncate is 1
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27141 Bug ID: 27141 Summary: QueryWeightFields should be 0 on new installs since QueryAutoTruncate is 1 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Since QueryAutoTruncate automatically disables QueryWeightFields, it does not make sense that both are set to 1 in "./installer/data/mysql/sysprefs.sql" I think that we should have QueryWeightFields set to 0 for new installations. It would even be tempting to set QueryWeightFields to 0 where QueryAutoTruncate is set to 1 on existing installs, except that someone might be (unwisely) trialling different Query* settings before/during a Koha upgrade. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 28822] New: SIP logins add to login attempts?
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '23

02 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28822 Bug ID: 28822 Summary: SIP logins add to login attempts? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org >From Agnes Rivers-Moore on bug 21190: Ah - there might be a problem with Koha counting SIP logins as 'failed' attempts. I could not see it before, but thanks to this enhancement I do see that the total of login attempts goes up by one when I log in to Overdrive Libby, and it is not reset to zero again - even though the login is successful. We had found more patrons complained of being locked out of the OPAC when they had not had 8 failed login attempts. If SIP login adds one every time, and does not clear back to zero, people using SIP products can come back to the Koha OPAC and find themselves locked out. I am on Koha 20.11 It may be this needs to be a separate new bug - anyone interested to describe what's not working as expected with SIP logins? (and possibly other kinds of external login too...) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 27977] New: Internal server error when placing hold if previously uploaded records have no item type set
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 Bug ID: 27977 Summary: Internal server error when placing hold if previously uploaded records have no item type set Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cmurdock(a)ccfls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is a weird one. If a batch of records are uploaded through the Stage MARC for import tool, and the items have no item type set, an Internal Server Error happens when staff tries to place a hold on any records cataloged *after* that, even if they do have an item type set. I stumbled upon this when staff imported some barebones "on order" records from Baker & Taylor and forgot to use the MARC modification template I'd created for them to set the item type, homebranch, holdingbranch, etc. Later a staff member at another library cataloged some items manually and tried placing a hold on one of them and got the Internal Server Error. In the logs, I see "Can't call method "notforloan" on an undefined value at /usr/share/koha/lib/C4/Reserves.pm line 1349" when the ISE occurs. Also it doesn't seem to happen every time, but what clued me in was another error when attempting to place a hold, about an item not having an itemtype set from a completely unrelated record. I investigated that and found that it was in the batch with no item type set. To reproduce: - Upload a batch of records with no item type set - Catalog some additional items - Try to place a hold on one of the items cataloged in the last step, via the staff interface (haven't tested with the public catalog) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 27989] New: MARC subfield structure can pick subfields from 100 instead of 10
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27989 Bug ID: 27989 Summary: MARC subfield structure can pick subfields from 100 instead of 10 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This happens when tag is 10 instead of 010. One simple way to reproduce is to change the URL. staff_URL/cgi-bin/koha/admin/marc_subfields_structure.pl?tagfield=10&frameworkcode= yields the same as staff_URL/cgi-bin/koha/admin/marc_subfields_structure.pl?tagfield=100&frameworkcode= instead of staff_URL/cgi-bin/koha/admin/marc_subfields_structure.pl?tagfield=010&frameworkcode= -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 27891] New: New DIN-oriented order print format (PDF-export) - layout2pagesdinde
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27891 Bug ID: 27891 Summary: New DIN-oriented order print format (PDF-export) - layout2pagesdinde Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.m.oehme+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A new order print format (layout2pagesdinde), inspired by the german DIN format, should be added, so the generated document can be send to booksellers without the need of additional pages. A draft is generated by me and is available via GitHub (https://github.com/mmo74/koha-layout2pagesdinde.pm) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2