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

[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

[Bug 27879] New: Koha::Hold::is_at_destination function should be removed
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27879 Bug ID: 27879 Summary: Koha::Hold::is_at_destination function should be removed 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently Koha::Hold::is_at_destination looks to be unnecessary and it could be replaced with Koha::Hold::is_waiting. However, to make sure nobody adds any code paths in the future we should add some checks to Koha::Hold::set_waiting so that it wouldn't allow set Hold waiting if the item's holding branch is not the hold's pickup library. We should also make sure that e.g. a transfer cannot be initiated for a waiting hold without the hold status going to in transit. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 27870] New: Add holds table at /opac-user.pl#opac-user-holds to Table Settings
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27870 Bug ID: 27870 Summary: Add holds table at /opac-user.pl#opac-user-holds to Table Settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The holds table in the patron account on the OPAC should be configurable via table settings. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 20463] New: Create an index for LDR, pos 19 - Multipart resource record level
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20463 Bug ID: 20463 Summary: Create an index for LDR, pos 19 - Multipart resource record level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org In order to be able to limit a search to sets or series of a specific type, it would be nice if Zebra/Elasticsearch allowed us to search on an index for LDR, pos. 19: http://www.loc.gov/marc/bibliographic/bdleader.html -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26