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

[Bug 42367] New: OPACPopupAuthorsSearch doesn't work with elastic, only zebra
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '26

15 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42367 Bug ID: 42367 Summary: OPACPopupAuthorsSearch doesn't work with elastic, only zebra Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org 1. Create 2 authority records (TOPIC_TERM) with 150s of a Technology x Religious aspects x Christianity and a Digital media x Religious aspects x Christianity 2. Create biblio with 2 x 650s which are linked to these by searching for them and save the biblio. 3. Duplicate the biblio and just change the 245 title 4. Ensure OPACPopupAuthorsSearch is set to "Show" (syspref) 5. Set searchengine to Zebra (with a built index) 6. Search in OPAC for your biblio 7. Click on subject terms area and pop up appears 8. Select both check boxes and "search" 9. Note your 2 biblios appear 10. Set searchengine to Elasticsearch (with a built index) 11. Repeat 6-8 above 12. No results found! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 31131] New: MARC21: XSLT links for 776 do not honor UseControlNumber when set to Don't use
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '26

15 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31131 Bug ID: 31131 Summary: MARC21: XSLT links for 776 do not honor UseControlNumber when set to Don't use Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org If a record has a value in 776$w, this is used for linking even if UseControlNumber is set to Don't use. To test: 1) Make sure UseControlNumber is set to Don't use 2) In Administration > MARC bibliographic frameworks, add field 776 to the editor 2.1) Go to Administration > MARC bibliographic frameworks 2.2) Next to the Default framework, click Actions > MARC structure 2.3) Search for 776 2.4) Next to field 776, click Actions > Edit subfields 2.5) Go to tab t, check the Editor box 2.6) Go to tab w, check the Editor box 2.7) Click Save changes 3) Go to Cataloging and add a new record 4) Fill in the required fields 5) Enter values in 776$t and 776$w 6) Save the record (no need to add items) 7) Go to normal view in staff interface 8) Hover mouse cursor over the link generated for Additional physical formats --> The link uses the control number 9) Open the record in the OPAC 10) Hover mouse cursor over the link generated for Additional physical formats --> The link uses the control number -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41407] New: OPAC hold history sorts newest to oldest but hides newest to limit to 50
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41407 Bug ID: 41407 Summary: OPAC hold history sorts newest to oldest but hides newest to limit to 50 Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Sort of hold history on the opac is unintuitive. It seems like if it's sorting newest to oldest, it should show the 50 newest holds, not active holds then oldest->newest holds until 50. To recreate on main: 1. Allow to override holds in system preferences 2. Allow borrowers to see HoldHistory in the OPAC 3. place at least 51 holds for a single patron. 4. Backdate some of the hold dates to past days, set one of them to be newer than the rest. 5. log in as that patron on the OPAC 6. Go to the holds history 7. observe the 50 holds and see that your newest one doesn't show 8. click the link to view all and see your newst one does show. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 14962] Temp Shelving Location / On Display Module
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Michael Adamyk <michael.adamyk(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael.adamyk@bywatersolut | |ions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31171] New: Remember user-selected sort in a given session for Purchase Suggestions
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31171 Bug ID: 31171 Summary: Remember user-selected sort in a given session for Purchase Suggestions 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: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Would it be possible to filter by manager or collection or any other sort column, and have Koha remember the settings between actions? It's annoying and slows down work to have to re-sort the list after each action to try to find next title in your list after you do something. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 16063] New: logic from overdue_notice.pl should be moved into a module
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16063 Bug ID: 16063 Summary: logic from overdue_notice.pl should be moved into a module Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Large parts of the logic from overdue_notice.pl can and should be moved into a module. This would a) Allow for unit tests b) Allow the code to be shared with other parts of Koha c) De-couple the notice generation and patron debarment functions of overdue_notice.pl d) Fix Bug 2389 - overdue_notices.pl needs a test mode -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 20962] New: Overhaul to notices
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Bug ID: 20962 Summary: Overhaul to notices Change sponsored?: Sponsored Product: Koha Version: unspecified Hardware: All URL: https://wiki.koha-community.org/wiki/Notices_Overhaul_ RFC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org Deadline: 2018-11-01 Currently notices are run using effectively two separate systems. Overdue notices run using their own cron job, whilst everything else is either queued by the advance_notices cron or directly added to the message queue. Additionally, print overdues are treated differently to other overdues. This means the options available for print overdues considerably lag those available for other notice types, and there are confusing discrepencies between overdues, other notices, and print overdues and everything else. Note that this enhancement is primarily aimed at modernising the way paper (postal) notices are managed, but as part of that it moves overdues under the same structure as other notices. # Step 1 - Move Overdues into member messaging preferences This should allow patrons (or staff on behalf of patrons) to: 1. Select one or more notification methods (SMS, email etc) 2. Choose not to be notified about Overdues at all 3. Choose to receive a digest for overdues # Step 2 - Enable 'postal' as a specific option rather than simply a fallback,for all notice types # Step 3 - option to process all print notices together # Step 4 - extend <item> tags to other circulation notices # Step 5 - Allow for 'digesting' of all notices in queue regardless of type # Step 6 - Allow circulation notices to be created for any item status change More detail is provided in the RFC - once we have community feedback the details may change slightly. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 20475] New: Patrons receiving both email and print overdue notices
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20475 Bug ID: 20475 Summary: Patrons receiving both email and print overdue notices Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When attempting to send overdue notices through both email and SMS, a print notice will be generated if *either* email or SMS fails. Ideally, a print notice would only be sent if *both* email and SMS fail. Currently, enabling both email and SMS overdue notices results in patrons receiving a print notice in addition to either email or SMS. To test: 1: Set overdue notices for a given patron category to send in both email and SMS 2: Create a patron in that category with a valid email address but no SMS number 3: Check an item out to the patron and set the due date to a past date that will generate an overdue notice 4: Run notices 5: Confirm that both email and print notices have generated While this bug concerns a specific instance of duplicate notices, overdue notice generation and failover also presents a larger opportunity for increased customizability and clarity. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 41148] New: Targeting specific attributes or restrictions for modification/deletion
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41148 Bug ID: 41148 Summary: Targeting specific attributes or restrictions for modification/deletion Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Batch patron modification needs some fields to match targeted attributes or restrictions. These elements in patron records can have more than one instances, and it would be helpful to have something to match against to confirm the proper target. As is, for example, if a set of patrons have multiple restrictions, it is impossible to clear a specific restriction from the group. Your only option in batch modification is to clear them all. If there was a text box next to the option for targeting, we could use it to specify specific text within the targeted restriction or we could have an option for an exact match. Then we could either update the comment or clear it altogether. Thoughts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 41001] New: Dismissing the "Run now" modal breaks functionality
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41001 Bug ID: 41001 Summary: Dismissing the "Run now" modal breaks functionality Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk To recreate: - create a data ERM provider /cgi-bin/koha/erm/eusage/usage_data_providers/add - dummy data should be sufficient - then go to data providers list /cgi-bin/koha/erm/eusage/usage_data_provider - open web development tools console (F12 firefox) - click on "Run now" - dismiss dialog by clicking outside the modal! - click again on "Run now" - check the logs for errors - any other clicks to create a modal won't work now ("run now", "delete") -- You are receiving this mail because: You are watching all bug changes.

1 25