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

[Bug 23333] New: Course Reserves: Instuctor search box positioning
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23333 Bug ID: 23333 Summary: Course Reserves: Instuctor search box positioning 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: claire_gravely(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 91567 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91567&action=ed… Screenshot When creating a new course in the course reserves module the "Instructor search" box is oddly positioned. Perhaps it could be moved more in line with 'Instructors'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22456] New: Customers Cancelling their Pending Holds
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22456 Bug ID: 22456 Summary: Customers Cancelling their Pending Holds Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: christofer.zorn(a)ajaxlibrary.ca QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Good morning! I'm not sure if I should have piggybacked this off of the previous ticket, but I'd like to open the discussion on bug 18856 again. We'd like the ability to have patrons cancel their holds once they have been pulled by staff and are awaiting pick up. Our previous catalogue (Bibliocommons) allowed the cancellation of holds once it as captured. This feature was well like and used by our patrons who had determined they didn't need/want the item any longer. This gave the perception that they were freeing up the item for the next person. We have fielded a number of grumpy comments since our migration about the inability to perform this functionality. >From my perspective, if we're allowing patrons to place holds and cancel them before they're captured, we should offer the ability to cancel them up until they're picked up. At the very least, this should be a system option to allow the Library to choose whether they'd like to enable this functionality. Even if the implemented functionality is a placebo for the user ... offer them the ability to cancel the hold and have it remove from their account. As long as optically it appears they've cancelled the hold, there is no harm. If desired, a report could be run to allow staff to pull those items from the shelf if needed. I'm more than happy to elaborate if needed on this, but I feel that this is a feature that is currently missing from Koha that would be a boon to customer service. Thanks Christofer -- You are receiving this mail because: You are watching all bug changes.

1 166

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

02 Sep '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 75

[Bug 33092] New: Add ability to search within a list
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 Bug ID: 33092 Summary: Add ability to search within a list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be really helpful to be able to search within a list in both the OPAC and the staff interface. For instance, in both the staff interface, if you are viewing a public list with a lot of items on it, you do not have the ability to see if a specific item appears on the list. This is a needed functionality with larger lists. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 18062] New: Damaged Status shows unavilable in results
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18062 Bug ID: 18062 Summary: Damaged Status shows unavilable in results Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When performing a search in the OPAC or staff client and the results include an item that is marked "Damaged" the status shows unavailable on the results page. When you view the detailed view of the record, the item appears as available. Although the item can still be checked out, it is confusing for the patron when they see the unavailable status. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 26866] New: Items table on additem should sort by cn_sort
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26866 Bug ID: 26866 Summary: Items table on additem should sort by cn_sort Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 To recreate: - create a bib - add three items with source of classification LCC, call numbers: -- JC43 .G6 1890 -- JC330 .F74 2000 -- JC480 .R63 2006 - on additem.pl, sort the items table by "Full call number" - notice items are order incorrectly, going 330, 43, 480 - use a report to pull the cn_sort values for your 3 items, confirm that ordering by cn_sort in your report correctly orders them 43, 330, 480 We should use cn_sort here to get them in the correct order. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 31487] New: Add emails to message queue by longoverdue script options
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31487 Bug ID: 31487 Summary: Add emails to message queue by longoverdue script options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some customers request the possibility of sending an additional reminder when processing longoverdues. I think this may be useful for some and given that it remains an option, it does not handicap those who do not want to use it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 33557] New: Add a system preference to disable/enable thesaurus checking during authority linking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33557 Bug ID: 33557 Summary: Add a system preference to disable/enable thesaurus checking during authority linking Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 30280 added support for multiple thesauri, however, this is a major change in behavior. Prior to this patch, heading from different sources would all link to the same authority, and auto generated authorities would link to any source. After this patch, however, a library will need to reindex their authorities after upgrade or face linking issues. For libraries who auto create authorities, there is the potential for generating a new set of authorities for any record from a differing source. In order to minimize disruption, we should provide a system preference, disabled by default, to allow libraries to opt in to thesaurus checking -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 27603] New: Add API for lists management
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '26

01 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27603 Bug ID: 27603 Summary: Add API for lists management 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: oleonard(a)myacpl.org Created attachment 116256 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=116256&action=e… Screenshot of the list modal idea I was playing around with making the list add form a modal instead of a popup, and while it can be hacked together as things are now it really would be better to have an API to work with. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32122] New: Wrong permissions check on item circulation alerts
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '26

31 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32122 Bug ID: 32122 Summary: Wrong permissions check on item circulation alerts 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 14391 added granular permissions for the administration module, however, there was a mismatch in the check on item circulation alerts and the new permission -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10