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

[Bug 14180] Make "Always show checkouts immediately" a global setting
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14180 Aude Charillon <aude.charillon(a)openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Needs documenting |RESOLVED --- Comment #43 from Aude Charillon <aude.charillon(a)openfifth.co.uk> --- Added to the Koha Manual. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14670] Add 'cite' option to detail page in OPAC
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14670 Marion Durand <marion.durand(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39902 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39902 [Bug 39902] "Cite" feature - UNIMARC : publisher in 214 is not taken into account -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24101] New: Due date to on-site loans according to the calendar and possibility to renew on-site loans
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24101 Bug ID: 24101 Summary: Due date to on-site loans according to the calendar and possibility to renew on-site loans Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have reading rooms, where patrons can have their on-site loans available for them for a long time - even a year or more! (That is, if no one else needs that item in the meanwhile, and makes a hold for it.) We wish to be able to distinguish the on-site loans from the checkouts they take home. The on-site option is good for this, because it shows clearly to the patrons and to the staff that the loans are on-site. However, we need two improvements to Koha for this. First, we need the option to set the due date automatically according to the calendar and the circulation rules, taking into account the holidays and the loan period that is set to the patron and to the item. In addition, we need the option for the patrons to be able to renew their on-site loans, too. Now the on-site loans are non-renewable, so if the patron needs them longer than what is set to due date originally, it would be good for them to be able to renew the loans themselves through our OPAC. Now the renewal is impossible altogether. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 39901] New: Transport type not recognized
by bugzilla-daemon＠bugs.koha-community.org 14 May '25

14 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39901 Bug ID: 39901 Summary: Transport type not recognized Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, philip.orr(a)lmscloud.de As outlined in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13498#c16 several slips do not set at transport type and thus fall back to use the _email_ template even though they are meant to be pritned and the print template may even exist. Given Bug 13498 is quite long standing and there might be no easy solution as outlined in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13498#c17 it might be worth a notice in the manual for the slips affected. (Reason: it is not clear to the uninitiated what's going on if she is working on a template that seems to never end up in the system. "But it's there. Why?!") -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[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