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

[Bug 22562] New: Add ItemHoldingLibrary to ReservesControlBranch
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '25

13 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22562 Bug ID: 22562 Summary: Add ItemHoldingLibrary to ReservesControlBranch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 35716] New: Duplicated assets in both koha-tmpl/intra-tmpl and koha-tmpl/opac-tmpl
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '25

12 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Bug ID: 35716 Summary: Duplicated assets in both koha-tmpl/intra-tmpl and koha-tmpl/opac-tmpl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, julian.maurice(a)biblibre.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com There are some JS assets duplicated in koha-tmpl/intra-tmpl and koha-tmpl/opac-tmpl. 100% match: ./koha-tmpl/opac-tmpl/bootstrap/js/i18n.js ./koha-tmpl/intranet-tmpl/js/i18n.js 100% match: ./koha-tmpl/opac-tmpl/bootstrap/js/Gettext.js ./koha-tmpl/intranet-tmpl/js/Gettext.js ~95% match: ./koha-tmpl/opac-tmpl/bootstrap/js/coce.js ./koha-tmpl/intranet-tmpl/js/coce.js ~95% match: ./koha-tmpl/opac-tmpl/bootstrap/js/cookieconsent.js ./koha-tmpl/intranet-tmpl/prog/js/cookieconsent.js ~80% match: ./koha-tmpl/opac-tmpl/bootstrap/js/ill-availability.js ./koha-tmpl/intranet-tmpl/prog/js/ill-availability.js ~50% match: ./koha-tmpl/opac-tmpl/bootstrap/js/basket.js ./koha-tmpl/intranet-tmpl/prog/js/basket.js Some of the differences in the above pairs may have been due to requirements specific to only staff or to only OPAC, or it may also have been the case that they have fallen out of sync over the years with some enhancements being added to one of the pair and not the other. I don't know what the best solution for this would be (if one is needed) but developing bug 35604 I need to have the same JS file on both intra and OPAC and feels bad to have to copy the same file to 2 different places. I'm only looking for JS files but I know this is also the case for images, maybe some CSS and other assets. Could we consider having a koha-tmpl/shared-tmpl directory, or have some of these overlapping assets only exist once and have them be duplicated for each interface during build, or yet another better option? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 34864] New: Allow for Web Pages to be duplicated
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34864 Bug ID: 34864 Summary: Allow for Web Pages to be duplicated Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, when creating web pages, you can create a page for one branch specifically but can't pick visibility to multi-libraries. Thus creating the need to create the same page multiple times if needed. It would be nice to allow for libraries to duplicate an existing page when needing to create a web page for multiple branches. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 36119] New: Bookings to collect needs a print option
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36119 Bug ID: 36119 Summary: Bookings to collect needs a print option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Depends on: 33736 A a print option to the bookings to collect report. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33736 [Bug 33736] Add bookings to collect circulation report -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 38016] New: Relabel booking precaution column heading in circulation rules tables
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38016 Bug ID: 38016 Summary: Relabel booking precaution column heading in circulation rules tables Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 34440 In the circulation rules there are 2 tables with 2 new columns named: * booking preparation period * booking precaution period While the first is before the booking, the second is after the booking is returned, but that's not clearly reflected in the name. Some alternative suggestions we came up with: A) * booking lead period * booking trail period B) * booking warm-up period * booking cool-down period C) * booking pre-buffer (days) * booking post-buffer (days) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34440 [Bug 34440] Add warm-up and cool-down periods to bookings -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 36536] New: Make REST API's validateUserAndPassword update borrowers.lastseen
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36536 Bug ID: 36536 Summary: Make REST API's validateUserAndPassword update borrowers.lastseen 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: magnus(a)libriotech.no CC: tomascohen(a)gmail.com Since ILS-DI (which specifically means the AuthenticatePatron verb) is an option that can be selected for TrackLastPatronActivityTriggers, I would expect the validateUserAndPassword of the REST API to also contribute to updating borrowers.lastseen. Since there is no separate option for activalting it, I thought maybe the REST API is considered so much "core" to Koha that the logins are tracked when "Logging in" is activated as an option for TrackLastPatronActivityTriggers. But it looks like it is not. To reproduce in KTD: TrackLastPatronActivityTriggers = [Select all] RESTBasicAuth = Enable Check the lastseen value of the "koha" user in the database: select borrowernumber, lastseen from borrowers where borrowernumber = 51; The value should be NULL, or some past timestamp. Run this script: https://wiki.koha-community.org/wiki/REST_API:_Checking_username_and_passwo… Check the lastseen value of the "koha" user again. I would expect it to have been updated when the script ran, but it is not. Not sure if validateUserAndPassword should be considered as just another way of "Logging in", or if it should be a separate option for TrackLastPatronActivityTriggers, but the latter would give maximum flexibility. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 37651] New: biblio->current_holds and item->current_holds do not respect ConfirmFutureHolds
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37651 Bug ID: 37651 Summary: biblio->current_holds and item->current_holds do not respect ConfirmFutureHolds 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com See also bug 37650. When we consider ConfirmFutureHolds to build the holds to pull list, we actually could say that these holds, probably only one or two days ahead, are current holds too. Currently, they are just completely ignored. But e.g. having a library depot further away require collecting those items earlier etc. At least the majority of calls look like they could use the lookahead days from ConfirmFutureHolds. Filed as enh, but very close to a bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 36278] New: Relabel "Gone no address"
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36278 Bug ID: 36278 Summary: Relabel "Gone no address" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Many libraries find the "Gone no address" patron account flag awkwardly phrased/named. Perhaps "Address block", "Wrong address", "Address correction needed", or similar would more clearly indicate to library staff what this flag does. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 36453] New: BlockExpiredPatronOpacActions should allow multiple actions options
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36453 Bug ID: 36453 Summary: BlockExpiredPatronOpacActions should allow multiple actions options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 34597 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34597 [Bug 34597] Expired patrons can still place ILL requests through OPAC -- You are receiving this mail because: You are watching all bug changes.

1 79

[Bug 32604] New: Patron categories upper age limit not respected when creating a patron
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '25

10 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32604 Bug ID: 32604 Summary: Patron categories upper age limit not respected when creating a patron 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha treats patron categories upper age limit inconsistently. E.g. if child patron category's upper age limit is 18, one is still able to add child patron who is 18 years old. However, when cronjob update_patrons_category.pl is run, patrons over and exactly aged 18 are considered overaged and their categorycode is updated. We should either fix patron creation or cronjob to avoid confusion. To test: 1. Add upper age limit as 18 for child patron category. 2. Create a child patron whose age is 18. 3. Save. => Patron is saved successfully. 4. Run cronjob update_patrons_category.pl with verbose option. perl update_patrons_category.pl --too_old --from CHILD --to ADULT -v => Note that patron is reported as updated (or would have updated) as an adult patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22