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

[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 26166] New: Patron verification through SMS one time code
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26166 Bug ID: 26166 Summary: Patron verification through SMS one time code 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Often we have a patron that will call to do something with their account and cannot because they don't have their card on them or they have lost their card. It would be FANTASTIC if there was a button on the account, for those that have SMS messaging setup, to send them a one-time code that they could read back to us to verify that it is them. I could also see this as a validation process for setting up SMS messaging on the patron (OPAC) side. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38703] New: Merged patrons should keep the most recent lastseen date
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38703 Bug ID: 38703 Summary: Merged patrons should keep the most recent lastseen date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Let's say a patron has duplicate accounts, account #1 and account #2, with the following data: lastseen Account #1 2024-05-01 Account #2 2024-11-15 Let's say a staff member merges the duplicate accounts and chooses to keep account #1 based on whatever criteria they use to decide. Currently, account #1 would keep its lastseen date of 2024-05-01. Since the lastseen date may be used to determine account retention and automatic renewal, it would make more sense to keep the more recent lastseen date in this case, especially for patrons who use the library relatively infrequently. (As an extreme example, I recently found a patron account in our system that has a lastseen date from 5 years ago yet also still has current checkouts from earlier this year!) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 38301] New: Add option to show holding table filters bu default
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38301 Bug ID: 38301 Summary: Add option to show holding table filters bu default Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com After Bug 33568 one must click 'Show filters' after the holdings table loads to see the various filters. I would be nice if there was an option to have those filters expanded by default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 33538] New: Allow for independent shibboleth autocreate and sync mapping
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33538 Bug ID: 33538 Summary: Allow for independent shibboleth autocreate and sync mapping Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: pgsengstock(a)wisc.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Shibboleth auth's autocreate and sync functions both rely on the same //shibboleth/mapping block in koha-conf.xml. Because autocreate requires mapping and/or defaults for branchcode and categorycode, this has the undesired affect of overwriting manual edits to borrowers on later syncs if the those fields are not delivered via shibboleth and explicitly mapped. Example: 1) Patron signs in for first time and borrower account is autocreated with a default branch and categorycode. 2) Staff update patron to set new branch and category codes as needed (e.g. from "SSOAUTH" to "MAINLIB"). 3) On next sign-in, patron's mapped data is synced, but branch and category codes are overwritten with the defaults. Suggested workaround is to differentiate //shibboleth/autocreatemapping vs //shibboleth/syncmapping. This allows greater control over which fields are mapped for autocreate vs sync. This schema change would not be backward compatible, though. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 23010] New: If an item is checked out or in transit it should not be able to be marked withdrawn
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23010 Bug ID: 23010 Summary: If an item is checked out or in transit it should not be able to be marked withdrawn Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Currently an item can be marked withdrawn if it is checked out to a patron or in transit from one branch to another. This causes confusion for staff checking an item back in or receiving the transfer. If an item is checked out or in transit it should not be able to be marked withdrawn. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 107

[Bug 37569] New: Serials without history cannot be edited
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37569 Bug ID: 37569 Summary: Serials without history cannot be edited Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Serials cannot be edited if there is no history associated to the serial. Fetching a subscription matching a given serialnumber results in an hashref containing two fields named serial number. One of them is undef and is used by the form and is therefore not submitted at the end. This is not supposed to happen since creating an exemplary automatically creates a new exemplary, but if serials are created through DB, they are not editable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 35722] New: Item transfer operations should be available from the API
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35722 Bug ID: 35722 Summary: Item transfer operations should be available from the 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: martin.renvoize(a)ptfs-europe.com CC: tomascohen(a)gmail.com We don't expose the item transfer queue in the API yet.. we should. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 38600] New: NoticeBCC needs granularity
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '26

14 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38600 Bug ID: 38600 Summary: NoticeBCC needs granularity Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com As Koha adds more notices for new functionality, libraries should be able to customize what notices to have delivered as bcc notices so that they are receiving only the pertinent ones. When the system preference was only overdues, it made sense for it to be all or nothing. Now, NoticeBCC includes notices that libraries may not want to receive - like CART and LIST notices, for example. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1