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

[Bug 18962] New: Including valid system requirements in Koha manual
by bugzilla-daemon＠bugs.koha-community.org 22 Nov '25

22 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18962 Bug ID: 18962 Summary: Including valid system requirements in Koha manual Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org According to https://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#Introduction Ubuntu 14.04 is no longer supported - but the information given on the page https://koha-community.org/download-koha/ still says that Koha is "Actively supported for packages: Debian 7 (Wheezy), Debian 8 (Jessie), Ubuntu 14.04 (Trusty Tahr)". It would probably be a good idea to have correct and complete information about the system requirements of Koha at the very beginning of the manual for every Koha version as it is good practice for almost every other software. * the manual of every Koha version * the release notes of every Koha version (or a link to the respective manual) * https://koha-community.org/download-koha/ (or a link to the respective manual) The systems requirements can be changing with every new version, of course, thus it is not enough to say in the manual: "Full system recommendations can be found on the official Koha wiki along with the developer documentation: http://wiki.koha-community.org". I suggest the manual of every Koha version should include a section with the exact requirements for the respective Koha version, e. g. * supported Linux distributions * supported version of Apache HTTP Server * supported version of MySQL * supported version of Perl This would probably also be helpful for all the guys that are trying to install Koha on unsupported Linux distributions like CentOS, Redhat etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 24439] New: Bulkmarcimport.pl Update documentation for -match option
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24439 Bug ID: 24439 Summary: Bulkmarcimport.pl Update documentation for -match option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: carnold(a)dgiinc.com QA Contact: testopia(a)bugs.koha-community.org The -match option for bulkmarcimport says: -match=<FIELD> FIELD matchindex,fieldtomatch matchpoint to use to deduplicate fieldtomatch can be either 001 to 999 or field and list of subfields as such 100abcde This seems to indicate that you put a number in the FIELD parameter, but really you are putting the "Koha Search Index" text a comma and then the MARC field: -match=<KohaIndex,FIELD> or -match=Control-number,001 I was only able to figure this out because someone else was confused: http://koha.1045719.n5.nabble.com/bulkmarcimport-pl-AND-match-fails-when-tr… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16910] New: Authority search plugin in cataloguing stops at 15 pages
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16910 Bug ID: 16910 Summary: Authority search plugin in cataloguing stops at 15 pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is similar to the problem fixed in bug 2735, but for the authority search plugin in cataloguing: 1) Go to cataloguing 2) MARC21: open authority search plugin from 100$a for example 3) Notice, it won't page after page 15 -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 17361] New: Add item messages table and rest api endpoints
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17361 Bug ID: 17361 Summary: Add item messages table and rest api endpoints Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This enhancement is to add the ability to create item messages and perform crud operations on them via the rest api only. The interface will be determined on the bug it blocks. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 17297] New: Give librarians the ability to add messages to an item
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17297 Bug ID: 17297 Summary: Give librarians the ability to add messages to an item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some librarians would like the ability to leave messages attached to an item ( outside the scope of itemnotes and itemnotes_nonpublic ). This feature would give the librarians the ability to add and remove messages of arbitrary types defined in an authorised value list. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 27675] New: Default checkout, hold and return policy should indicate when set vs unset and should not set null rules
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27675 Bug ID: 27675 Summary: Default checkout, hold and return policy should indicate when set vs unset and should not set null rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com These policies can be set to blank, this affects the holds queue and presumably other areas. There needs to be a visual indication of the rule not being set vs the rule being set to blank - or the rule should not save when dropdown is set to 'Not set' To recreate: 1 - Go to Admin->Circulation rules and pick a branch with no rules set 2 - Under "Default checkout, hold and return policy" leave all fields blank and hit save 3 - Check the DB, five rules have been set: SELECT * FROM circulation_rules WHERE branchcode="BRANCH"; 4 - In the staff client, click 'Unset' 5 - There is a warning, but no visible change 6 - Check the DB, the rules are gone -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22492] New: Advanced editor - Rancor - AdditionalFieldsInZ3950ResultSearch
by bugzilla-daemon＠bugs.koha-community.org 21 Nov '25

21 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22492 Bug ID: 22492 Summary: Advanced editor - Rancor - AdditionalFieldsInZ3950ResultSearch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- With Bug 12747 we added the AdditionalFieldsInZ3950ResultSearch. This currently works in the z39.50 search for the basic editor and in the z39.50 search in acquisitions, but does not work when starting the z39.50 search in the advanced editor for cataloging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 22178] New: Add start and end date for repeated holidays
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22178 Bug ID: 22178 Summary: Add start and end date for repeated holidays Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- When weekly or other repeating holidays are changed it will always effect dates in the future, but also in the past. For fine calculation and other reasons this can cause problems. It would be nice if it would possible to start and and repeated holidays at specific dates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 27464] New: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27464 Bug ID: 27464 Summary: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: madamyk(a)ckls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If one tries to create a "local use only" item type, there isn't a good way to make it impossible to place holds for anywhere other than its home branch. Setting restrictions on it in Circ rules allows any staff member with permissions to override the hold restrictions. Another option is setting an item to a lost status, but this is certainly not ideal: it clears the status every time the item is scanned, and it affects how it appears in the OPAC. What if there were a way to have finer control over the AllowHoldsPolicyOverride system preference? For instance, allow hold overrides as a separate permission for overriding circulation rules vs. overriding patron restrictions. It seems logical that overriding a restriction to check out to a patron is quite a bit different from ignoring specific circulation rules (if that makes sense). Perhaps another way to work around this would be a checkbox in the circulation rules with an option to "Ignore staff overrides" or something similar? It could be turned on or off for each individual circulation rule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 26744] New: Log changes to extended patron attributes
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26744 Bug ID: 26744 Summary: Log changes to extended patron attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It looks like changes to a patron's "extended patron attributes" are not logged, when BorrowersLog is on. They should probably be. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 95