October 2022 - Koha-bugs - lists.koha-community.org

[Bug 17596] New: Simplify accounting UI in staff client
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17596 Bug ID: 17596 Summary: Simplify accounting UI in staff client Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This bug is omnibus for our effort on simplifying accounting UI and workflow. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 28544] New: Add API's for account transactions
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '23

03 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28544 Bug ID: 28544 Summary: Add API's for account transactions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org This is an attempt at a refresh of bug 15165.. I hope to create a number of routes to manipulate accounts with both patron and anonymous transactions being taken into account. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 20944] New: Add routes to add credits and 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=20944 Bug ID: 20944 Summary: Add routes to add credits and debits to a patron's account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature 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 watching all bug changes. You are the assignee for the bug.

1 31

[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 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