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

[Bug 39898] New: waitingreserves.pl should keep the parameter "view all libraries" when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39898 Bug ID: 39898 Summary: waitingreserves.pl should keep the parameter "view all libraries" when cancelling a hold Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When viewing holds awaiting pickup (Circulation > Holds awaiting pickup) we can choose to view holds from all libraries by clicking a link "View all libraries". This choice is lost when doing an action (cancelling a hold), we return to the view for our library only. It would be needed to add a button to return to the default view (View my library) This can be reproduced from tab "Holds waiting", "Holds waiting past their expiration date" and "Holds with cancellation requests" To reproduce (from holds waiting tab): 1- Create multiple holds for pickup at different location for one or multiple user (2 holds to pickup from library A, 2 holds to pickup from library B) 2- From library A, check in some items filling the holds for library A, same from library B. 3- Go to Circulation > Holds awaiting pickup 4- Check that, by default, you only see holds from your current library 5- Click on "view all libraries" 6- Check that you can now see holds from all libraries and that the URL have the parameter "allbranches=1" 7- Cancel a hold by clicking on the button in the actions column 8- Check that you can now see holds from your library only and that the parameter "allbranches=1" is no longer present in the URL. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 33217] New: Allow different default sorting when click author links
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33217 Bug ID: 33217 Summary: Allow different default sorting when click author links Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using the facets for author, i.e. limiting a search, it makes sense to preserve the default sort order for the results (relevance, etc) When clicking on an author to search the catalog for all works by an author, it would be nice to be able to optionally specify sorting for the listing - i.e. publication date, or title -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 30845] New: OMNIBUS: Move holds checks into CanBookBeReserved/CanItemBeReserved
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30845 Bug ID: 30845 Summary: OMNIBUS: Move holds checks into CanBookBeReserved/CanItemBeReserved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 We have a number of holds checks: not for loan opacitemholds OPACHoldsIfAvailableAtPickup which are only checked in the script, and not our modules The api uses CanBook/CanItem BeReserved for checking validity of holds and is missing these checks We need to move the checks and cover them with unit tests -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 33801] New: Holds API doesn't follow holds policies like the staff/OPAC UIs
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33801 Bug ID: 33801 Summary: Holds API doesn't follow holds policies like the staff/OPAC UIs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au CC: tomascohen(a)gmail.com The Holds API let you place multiple holds against the same item, while the OPAC and Staff Interface will prevent you from placing a hold on the same item for the same patron twice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #26 from David Cook <dcook(a)prosentient.com.au> --- If we have different session cookies for staff and OPAC, we'll need to make sure that the API can cope with both, since it's the 3rd interface which gets shared by those two UIs. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 --- Comment #25 from David Cook <dcook(a)prosentient.com.au> --- (In reply to ddemick from comment #22) > (In reply to Katrin Fischer from comment #21) > > I think the patron category is not ideal, but maybe the web based self check > > could get its own sessions as well, while we are at it? > > I would support that too. Basically a way to force an auto-logoff for staff > but still be able to keep our self-check machines logged in for the full day. The web based self check should already have a timeout that clears the end user pseudo-session? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39471] New: WCAG 2.4:2.4.4 - Link Purpose (In Context)
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39471 Bug ID: 39471 Summary: WCAG 2.4:2.4.4 - Link Purpose (In Context) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org Across Koha's OAPC, links and buttons are generally very clear and contain suitable aria-label text. However, on the ‘Details for’ pages, there are repeated ‘Browse shelf’ links that require additional context to be clear. Solution: Ensure that the meaning of all links and buttons is clear without relying on surrounding content: • For text links, hyperlink the descriptive part of the sentence. Keep link text short and succinct so it can easily be identified and understood by screen reader users • For buttons, add an aria label or aria-labelledby attribute to provide the relevant context -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 29492] SPAM
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29492 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize(a)openfifth.co.uk> --- *** Bug 39471 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15428] Different timeout preference for OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acampbell(a)buttecounty.net --- Comment #24 from Avery Campbell (Butte County Library (CA)) <acampbell(a)buttecounty.net> --- Looks like it's been a while since the last update, but this would be very helpful for us, too. Staff don't need a short timeout, but the public do -- I don't have a way to count how many patrons placed holds on someone else's account because they weren't signed out, but I know it's happened. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39893] New: Show and make searchable translated and transliterated titles in OPAC
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39893 Bug ID: 39893 Summary: Show and make searchable translated and transliterated titles in OPAC Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: angela.berrett(a)familysearch.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 182392 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182392&action=e… Example of translated (242$a) and transliterated (246$a) titles We have a lot of international books in many languages even though we are an English-based library. We often create translated titles (242$a) and other varying titles (246$a) for these books. Sometimes we use the 246$a for the spine title if it differs from the main title, or if the publisher/author provided a translated/parallel title, or if we create a transliterated title. However, these titles do not appear in the OPAC (Aspen), nor are they searchable by these titles. We would like to see these titles to appear in the OPAC. If possible, make them searchable as well. -- You are receiving this mail because: You are watching all bug changes.

1 4