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

[Bug 33222] New: Checkin message does not display when book is overdue and borrower has manual restriction
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '25

22 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33222 Bug ID: 33222 Summary: Checkin message does not display when book is overdue and borrower has manual restriction Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: janet.mcgowan(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Overview: When a borrower with a manual restriction returns an overdue item the returns.pl page displays the checked in items table showing the summary of returned items but there is no Check in message displayed indicating that the borrower has a restriction. If the same restricted patron returns an item that is not overdue you see the Check in message indicating "Reminder: Patron has an indefinite restriction." (or Reminder: Patron was earlier restricted until 31/03/2023. - if the patron is restricted to a specific date). Steps to Reproduce: User has 1 overdue item (I used special due date to set to date in the past) and 1 item that is not overdue. Create a restriction on the patron record - e.g. indefinite restriction. Return the item that is not overdue - Checkin message shows "Reminder: Patron has an indefinite restriction." Return the item that is overdue - no Checkin message displays. Expected results: the Checkin message showing that a patron is restricted should display when returning an overdue book. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 28862] New: Add suffix to name field
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '25

22 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28862 Bug ID: 28862 Summary: Add suffix to name field Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Requesting the addition to the name field for suffix entries (Jr., Sr. III, etc.). Ideally it would be a drop-down box that could be prepopulated (auth_value?) with common entries; allowing for cleaner data and easier account viewing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 24260] New: REST Self Registration
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '25

21 Oct '25

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

1 4

[Bug 30299] New: Create a Registration API to allow for use of email verification when outside systems are registering patrons
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '25

21 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30299 Bug ID: 30299 Summary: Create a Registration API to allow for use of email verification when outside systems are registering patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com CC: tomascohen(a)gmail.com Some discovery systems (Aspen for instance) provide a self registration function. Currently the Koha preference 'PatronSelfRegistrationVerifyByEmail' cannot be utilized via the API. We propose to add two endpoints: 1 - Registration - This will take a borrower object, verify the required/unwanted fields, and create a patron modification request as on 'opac-memberentry.pl' when verification is enabled - The endpoint will take an option to send/suppress the email from Koha so that integrating systems may generate their own - The endpoint will take an optional return URL to be passed through when generating the verification email so the outside system can handle the verification - The endpoint will return the verification token 2 - Verification - The endpoint will accept the token generated above and complete patron creation as in opac-registration-verify.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 16207] New: Incorporate circulation and fine rules for library groups
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '25

20 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16207 Bug ID: 16207 Summary: Incorporate circulation and fine rules for library groups Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 I think we could simplify circulation and fine rules by incorporating library groups into the mix. For example, I have 27 libraries, and 8 of them follow the same set of rules that are different from the defaults. So, what if instead of cloning these special rules to 8 different libraries (and who knows how many other duplicated sets of rules there are), we defined a set of rules for a library group. If the library is part of that group, it goes by those rules. I don't know if we want to use the same library groups that are already defined in the libraries and groups, or if we want to create a unique Circ rule group. Because, there is always the chance that one or more of the libraries in the 8 that are grouped together by affiliation or region could have a slightly different set of rules. However, I think rules by groups would make managing rules far less complicated than managing groups of cloned rules. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 18327] New: Reception date when receiving multiple issues for a subscription is not the good one
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '25

20 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18327 Bug ID: 18327 Summary: Reception date when receiving multiple issues for a subscription is not the good one Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When receiving several issues for a subscription (Serials > Serial collection > Multi receiving), the reception date is identical to the publication date instead of being the today date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 33363] New: More specific permissions for purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '25

17 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33363 Bug ID: 33363 Summary: More specific permissions for purchase suggestions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are a number of libraries that would like for their staff to be able to submit (and view existing) purchase suggestions from the borrower record, but not give the staff the ability to edit/manage/delete purchase suggestions. Currently if staff are given Suggestions Management/Manage Purchase Suggestions, and no Acq permissions, they are able to not only submit/view from the borrower record, but also access the purchase suggestion module and update/approve/delete purchase suggestions. If Suggestions Management is not turned on, then staff cannot enter a purchase suggestion from a borrower record, nor can they see them from the patron record to let the patron know what the status is. It would be helpful to have an addition permission level that would allow staff to enter a purchase suggestion from the borrower record, and view the existing purchase suggestions on a patron account. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 23731] New: Staff & OPAC both will display the DDC call number in XSLT but can't display the LC call number
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '25

16 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23731 Bug ID: 23731 Summary: Staff & OPAC both will display the DDC call number in XSLT but can't display the LC call number Change sponsored?: --- Product: Koha Version: 18.11 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 93597 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=93597&action=ed… staff view When looking at the display of the Bib record in both the staff and OPAC, the DDC number will display by default. However, there is no way for an LC number to display. It would be nice if they both displayed and the library could choose to hide one or both. Currently, it appears that it is displaying the 082 and 084, we would like to see it also display the 090 or 050 (or both) by default. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 29236] New: Allow OPAC News / HTML Customization contents to be set for library groups
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '25

16 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29236 Bug ID: 29236 Summary: Allow OPAC News / HTML Customization contents to be set for library groups Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org For the content sent to various OPAC pages/fields from the HTML Customizations interface (OPACNavRight, OPACHeader, etc), it would be helpful to be able to set those values for groups of libraries, rather than just individual libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27934] New: Using 'title' attributes on span fields for sorting is wrong
by bugzilla-daemon＠bugs.koha-community.org 16 Oct '25

16 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27934 Bug ID: 27934 Summary: Using 'title' attributes on span fields for sorting is wrong Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have some interesting code in our datatables wrappers to magically sort on 'title' attributes found in spans in table fields (When the headings are marked up with 'title-string' and 'title-number' classes). This is weird and a mis-use of the HTML title attribute. It results in tooltips being generated for all fields witch such values and often those tooltips are confusing/mismatched. We should replace these with either data- attributes or perhaps use hidden datatables columns for sorting? Basically.. there must be a better way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44