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

[Bug 27248] New: Allow to use list of barcodes/itemnumbers with Batch extend due dates tool
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '26

05 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27248 Bug ID: 27248 Summary: Allow to use list of barcodes/itemnumbers with Batch extend due dates tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org In some cases libraries want to use some more complicated criteria for selecting the items that they want to extend the due dates for. For these cases it would be great if SQL reports could be used to make a list that then can be uploaded to the tool, similar to how we manage other batch operations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 80

[Bug 23705] New: Add a syspref to enable record locking, so that when one record is opened to be edited, it's read only for other users
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '26

05 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23705 Bug ID: 23705 Summary: Add a syspref to enable record locking, so that when one record is opened to be edited, it's read only for other users Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: chris(a)bigballofwax.co.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It should be possible to allow Koha cataloguing to operate in a way where only one person can be editing a record at a time. This feature will add a syspref to enable that behaviour -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 31092] New: Upon importing batch records, if a full MARC record is found, only append the items; do not overlay a full MARC record
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '26

05 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31092 Bug ID: 31092 Summary: Upon importing batch records, if a full MARC record is found, only append the items; do not overlay a full MARC record Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: balestrieri(a)monterey.org QA Contact: testopia(a)bugs.koha-community.org When receiving items from our vendors, the full MARC records are sent in batches for import. We would like the ability to have koha only overlay our brief "on order" records that already exist in the system, not our full records already in our system. Currently, the only choice is to overlay ALL or NO records (choices are "Replace, Add, or Ignore") and to append the items, depending on the matching rule used (most users currently match on ISBN when importing books, audiobooks). Apparently, other ils systems have the ability to determine which existing records are brief and which existing records are full, and you can choose to only overlay the brief MARC records, leaving the full MARC records in tact, appending only the items. I understand the definitive markers are in the leader of the marc record. The leader will show the level of marc record it is. Most loaders will have a function to put this as one of the criteria. An example of an incoming Leader: =LDR 01429pam a2200385 i 4500 Position 17 is the encoding level. The above encoding level is blank, so it is a full level record. Encoding levels: Blank - full level record 1 - full level record 2 – less-than-full level record 3 – less than full level record 4 - less than full level record 5 – less than full level record 6 - less than full level record 7 – less than full level record 8 – less than full level (this is a prepublication record) It would be most convenient if koha would have an internal matching rule that allows for the user to overlay only existing records where levels 2-8 are in position 17 on the MARCs, ignoring any records with a "blank" or "1" in position 17 on existing MARCS, with the ability to still append all items. Right now, many of us in aquisitions need to create separate vendor accounts to order "added/existing" items only to avoid the constant overlaying of full MARC records in koha. We know any items arriving from these accounts already have full records in our system, so the vendor does not send full MARCs for any items ordered from these accounts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 31391] New: Staff-side recalls
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '26

05 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31391 Bug ID: 31391 Summary: Staff-side recalls 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Add functionality for recalls to be placed via the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 378

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '26

05 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 82

[Bug 23609] New: Tie patron gender to an authorized value
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '26

05 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23609 Bug ID: 23609 Summary: Tie patron gender to an authorized value Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the interest of allowing greater flexibility, it'd be great to have gender tied to an authorized value so libraries can edit/add/delete options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24535 Bug ID: 24535 Summary: Add the ability to have longer barcodes than 20 digits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, an item's barcode can only be up to 20 digits, it would be nice to increase this value to possibly a higher number such as 32. Koha recently increased the patron's barcode length to 32 and it was helpful to libraries. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 23185] New: Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store'
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23185 Bug ID: 23185 Summary: Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P1 - high Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, jonathan.druart(a)bugs.koha-community.org, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 21761 Target Milestone: --- +++ This bug was initially created as a clone of Bug #21761 +++ If we're adding triggers at the code level all over the place by overloading the store method we need to never ever let dbic handle it.. by allowing the 'update' method through we are exposing ourselves to places in the codebase skipping the store triggers. This would in effect bind us to the 'update_all' style of update call from dbic, which results in a loop over the affected rows so that in code triggers can be called per row rather than allowing any form of 'update all these rows to X' in one query. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21761 [Bug 21761] Koha::Object supports passing through 'update' which means we can side step 'set' + 'store' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are on the CC list for the bug.

1 71

[Bug 24712] New: Use YAML files for some of the update data
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24712 Bug ID: 24712 Summary: Use YAML files for some of the update data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Depends on: 13897, 24262 Bug 13897 with bug 24262 refine our translation process for install files converting the old SQL files used in the installer for mandatory and optional data into YAML files and adding processing to allow centralised translation of those files alongside the rest of the translation project. It raises the question, however, of how we should deal with the same data during upgrades. Currently we add the American English values with standard SQL in an atomicupdate file (copied into updatedatabase at push time). I'm envisaging we may be able to do away with the atomicupdates for this type of data insertion during upgrade and replace it with a step inside updatedatabase that pulls the data, translations and all from the yaml files. Opening this bug to discus and attempt such an implementation. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 [Bug 13897] Use YAML files for installer data https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24262 [Bug 24262] Translate installer data in YAML format -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 22994] New: Elasticsearch ability import mappings and facets settings
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '26

04 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22994 Bug ID: 22994 Summary: Elasticsearch ability import mappings and facets settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28