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

[Bug 33446] New: Revert transit status should have the option to cancel the item transfer as well
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446 Bug ID: 33446 Summary: Revert transit status should have the option to cancel the item transfer as well Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, when a hold's transit status is reverted, the item remains in-transit until the transfer is completed by a check-in. This makes sense if the item actually is still in-transit, but there are other situations in which this transit status is incorrect and may not be easy to remove. For example, in our system, we have HoldsAutoFill enabled. Occasionally there are exceptions where we don't want a book to be put in transit for a hold, but instead to remain available at its home branch. If the staff member reverts the transit status on the hold, the item still shows as In Transit. But they can't check in the item to complete the transfer without causing the hold to trap again. In this situation, the book shouldn't be showing as In Transit, but there's no simple way to remove that status. It's several extra steps at best to manually cancel the transfer (and most of our staff don't know how to do this, as manual transfers are not a normal part of our workflow, so many items retain an incorrect "In transit" status indefinitely). When a hold's transit status is reverted by the sending librarian because they're not planning on sending the book for whatever reason, it would be great if they could revert the hold transit status and cancel the item transfer all in one step. This could be something as simple as a checkbox option or a drop-down, so that the user can choose between "Revert transit status" versus "Revert transit status and cancel item transfer". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 30719] New: ILL should provide the ability to create batch requests
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30719 Bug ID: 30719 Summary: ILL should provide the ability to create batch requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Some interlibrary loan providers, for example Reprints Desk, allow for ILL requests to be submitted in batches. In the Reprints Desk case, a batch is created with the supplier, then requests are then submitted including the batch ID. Obviously, this workflow may differ according to supplier and these differences should be abstracted away into the supplier backend. For core Koha, we should provide the ability for it to recognise if a given backend can process batch requests. If so, we should provide an interface for creating and manipulating batches within Koha, then submitting a batch to the supplier. It should also be possible to view all batches and the contents of a given batch. The funding institution has defined the following workflow for creating and populating batches: - A encapsulating "batch" is created with a name and a requesting borrower - Requests are added to a batch via two methods: - In bulk: - A form which allows the user to paste in a collection of identifiers, such as DOI / PMID etc. - For each of these identifiers: - The request metadata should be populated via API queries to metadata suppliers, for example, PubMed API or LibKey/Browzine. This behaviour is governed by the presence of appropriate plugins. - (Optional) Once the metadata is populated for an item, we check for item availability via any installed ILL availability plugins - Individually: - A regular ILL request form, requests are added to the batch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 195

[Bug 35098] New: ILL batch is not displayed in ILL table
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35098 Bug ID: 35098 Summary: ILL batch is not displayed in ILL table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 35096 To reproduce, k-t-d: 1) Install FreeForm and enable ILLmodule, run: bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.…) 2) Install an ILL availability plugin (e.g. pubmed): https://github.com/PTFS-Europe/koha-plugin-api-pubmed/releases/tag/1.1.1 3) restart plack: koha-plack --restart kohadev 4) Create a new ILL batch, visit: /cgi-bin/koha/ill/ill-requests.pl 5) Click '+New ILL requests batch' 6) Input a name, '42' on the cardnumber and pick a library. Click 'Continue'. 7) On the identifiers textarea, insert '123' and click 'Process identifiers' 8) After the metadata has been retrieved, click the bottom 'Add items to batch' button, click 'Finish and view batch' 10) Go back to ILL requests table, visit: /cgi-bin/koha/ill/ill-requests.pl 11) On the top right of the table, click 'Columns' and enable Batch 12) Notice the batch column is empty for the request we just created within a batch Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35096 [Bug 35096] ILL request manage page explodes if it belongs to a batch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 30759] New: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30759 Bug ID: 30759 Summary: Add hint about the data that is sent via the Google Books API to OPACSuggestionAutoFill Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 14242 On bug 14242 Victor suggested to add a hint to the OPACSuggestionAutoFill system preference that explains about possible implications to data privacy and lists which data is sent via the Google Books API: (In reply to Victor Grousset/tuxayo from comment #118) > And meanwhile, should a small warning in the syspref description be added? > So the library can update their documents about their personal data > processing. > > Something like «Personal data processing: Google will receive the following > data: IP address, OS name, web browser version, preferred languages, and the > ISBNs of the books suggested.» Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 [Bug 14242] Use ISBN-field to fill out purchase suggestions using Google Books API -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 35130] New: Limit Item Types that can be checked in Via SIP2
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35130 Bug ID: 35130 Summary: Limit Item Types that can be checked in Via SIP2 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Similar to 34101, some libraries would like the ability to limit check in via SIP2 by item type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35369] New: SIP default 'Greetings from Koha.' message for patrons should be optional and configurable
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35369 Bug ID: 35369 Summary: SIP default 'Greetings from Koha.' message for patrons should be optional and configurable Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have a syspref / sip configuration option to remove or customize this message without having to use regex on the AF field -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 29720] New: Allow per-user customization of table settings
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29720 Bug ID: 29720 Summary: Allow per-user customization of table settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client 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 Table settings are currently global. Per-user customization would be great! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32419] New: Show availability in list view in staff interface
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32419 Bug ID: 32419 Summary: Show availability in list view in staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When viewing a list on the OPAC, you can see the item's availability. But in the staff interface, this information is not visible. To test : 1. In the staff interface, add an item to a list 2. View the list --> No availability is visible 3. Go to the OPAC and view the list --> You can see the availability of the item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 35142] New: Koha::Util::oclc_number should be removed in favor of Koha::Biblio::Metadata::Extractor
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35142 Bug ID: 35142 Summary: Koha::Util::oclc_number should be removed in favor of Koha::Biblio::Metadata::Extractor Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 30678, 34828 See bug 34828. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30678 [Bug 30678] Add OCLC_NO as option to OPACSearchForTitleIn https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34828 [Bug 34828] Add Koha::Biblio::Metadata::Extractor* classes -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 26197] New: Using Rancor while cataloging doesn't appear to check for existing records
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '26

16 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26197 Bug ID: 26197 Summary: Using Rancor while cataloging doesn't appear to check for existing records 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Upon testing this, while cataloging a new record using the basic editor Koha will find a duplicate record existing in Koha but didn't find the same duplicate using the Advanced Editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10