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

[Bug 35668] New: Change bookings dates, timeline does not update
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '25

31 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35668 Bug ID: 35668 Summary: Change bookings dates, timeline does not update Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To replicate: 1. Find an item and create a booking. Make a note of the dates in the Bookings table. 2. See the booking on the timeline. 3. Select the booking on the timeline. It should turn yellow and give the red cross-hairs to move the booking. Move the booking either left or right to change the dates. 4. A pop-up box asks to confirm the date change. Confirm. See the booking dates update on the bookings table, but the booking on the timeline reverts to its original booking dates. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 36669] New: Add ability to charge for bookings
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '25

31 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36669 Bug ID: 36669 Summary: Add ability to charge for bookings Change sponsored?: --- Product: Koha Version: unspecified 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: 29002 One can charge for reservations, we'd like to also add the option for charging for bookings. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002 [Bug 29002] Add ability to book items ahead of time -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 33221] New: Send WELCOME notices by sms too
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '25

31 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33221 Bug ID: 33221 Summary: Send WELCOME notices by sms too Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com WELCOME notices are sent only by email. This will make it possible to send them by sms too. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 26754] New: Budget plans need a note that no changes can be made when budget is locked
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '25

31 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26754 Bug ID: 26754 Summary: Budget plans need a note that no changes can be made when budget is locked 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 26496 At the moment, when looking at the budget planning page for a locked budget, you can manipulate the cells, but the save button is hidden. This is confusing. I suggest: - Remove the buttons for manipulating the cells - Make the cells display normally, not as input cells - Add a note Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26496 [Bug 26496] Budget plan save button doesn't save plans -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 24778] New: Move from Memcached to Redis to solve L1 caching issues?
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '25

31 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24778 Bug ID: 24778 Summary: Move from Memcached to Redis to solve L1 caching issues? 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Would it be worthwhile to switch from Memcache to Redis? Redis has pub/sub which in theory would allow all processes to listen for syspref changes and update their L1 caches if necessary. What made me think of this is bug 23640 I have no idea if this is worth the time and effort, but it seems like it would solve the major issue we have with memcached. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 28337] New: Add System-control-number index for authorities to MARC21 indexes
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28337 Bug ID: 28337 Summary: Add System-control-number index for authorities to MARC21 indexes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com https://www.loc.gov/marc/authority/ad035.html The 035 field in authorities can contain a system control number, this is useful for authority cleanup work as it can contain a non-Koha id for the record When importing, however, we cannot use this field for matching as it is not indexed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 32444] New: Identify patrons as a group or family unit
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32444 Bug ID: 32444 Summary: Identify patrons as a group or family unit 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com For years, Koha has used guarantors to link families together. Progress was made when we were able to link more than one person to a child. However, there are other areas where it might be beneficial to link patrons together that don't involve parents. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31329 proposes to block linked accounts when one is restricted. But before we do that, I think it might be worth looking at the guarantors a little bit and refine our approach with this functionality before proceeding with 31329 (sorry Wally!). I think guarantors should be updated to something more universal, linking any patron to any patron. Right now we limit it to linking a parent or guardian to a child. But what if we wanted to link a household. That might just be siblings in the same house. What if it was husband and wife? What if it was an organization? There are some great ideas with linked accounts, like what 31329 proposes. And I am sure that there are others. For example, maybe your library has some resources that you want to limit 1 per household. Right now we can't do that, but perhaps we could with a re-imagined linking system. What if we wanted to update information in the linked accounts? This would be a good start. What does this re-imagined linking look like? Perhaps: * Eliminate the limitation allowing the links to just child accounts. * Name the organizational grouping: Household, School name, business name, etc. * Identify and an all guarantors in the grouping. * Can the grouping exist without a guarantor? * If not, if the last guarantor is removed from the group, should someone else in the grouping be marked as guarantor, should the grouping be allowed to carry on without a guarantor, or should the grouping be dissolved? There may be other aspects we might want to consider in this functionality, but this is a good start. Once this is reworked, then we could look at options of linking blocks to particular groups, updating groups, circulation limitations to groups, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 33049] New: Breadcrumbs don't appear if you go directly to /cgi-bin/koha/erm/
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33049 Bug ID: 33049 Summary: Breadcrumbs don't appear if you go directly to /cgi-bin/koha/erm/ Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: dcook(a)prosentient.com.au CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com I was just comparing the following links: http://localhost:8081/cgi-bin/koha/erm/ http://localhost:8081/cgi-bin/koha/erm/erm.pl They're actually virtually identical, except that the breadcrumbs list isn't populated in the former link. The console also says the following: vue-router.cjs:39 [Vue Router warn]: No match found for location with path "/cgi-bin/koha/erm/" -- I'm actually a bit surprised that it works at all. In the plack.log, it shows that a GET for /intranet/erm/erm.pl In the Apache logs, it shows a GET for /cgi-bin/koha/erm/ Ah, it's because of a RewriteRule in debian/templates/apache-shared-intranet.conf That seems suboptimal... -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 36337] New: Hiding lists with OpacPublic breaks styling for language list
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36337 Bug ID: 36337 Summary: Hiding lists with OpacPublic breaks styling for language list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 33244 Added from the comment on bug 33244: Hello, [this patch] seems to have a side effect of the "Language" dropdown now being awkwardly placed on center-right (regardless of whether user is logged in our out). This is caused by the below CSS rules whose blame traces back to this patch, and removing them fixes the issue. #members { + flex-grow: 1; + justify-content: flex-end; Is this intentional change? I can only assume it's not, since I don't see any mention of this in the discussion. Screenshots of the problem: https://imgur.com/a/hDZvn7B It looks like this patch conditionally hides cart+lists. The CSS above then makes only language shown on the left, and the login on the right. But when things aren't hidden, it changes the original position. Should I create a new bug about this? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33244 [Bug 33244] Do not show lists in OPAC if OpacPublic is disabled -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 26791] New: Build Mojolicious controller replacement for export.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26791 Bug ID: 26791 Summary: Build Mojolicious controller replacement for export.pl 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As per my notes on Bug 8437, starting at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8437#c33, any Koha .pl script that needs to stream a large response to a client web browser is never going to work, so long as we're using Plack::App::CGIBin to create a PSGI handler. While I tried to create my own streaming version of Plack::App::WrapCGI, I found a third-party module to be buggy, and that writing my own would be prohibitive in terms of time and energy. It's also architectural glue code that we really might not want to maintain long-term. So I've concluded that an alternative would be to write a Mojolicious controller to replace export.pl. While CGI Koha can still use export.pl, when we're using Starman/Plack, we can redirect to the appropriate Mojolicious endpoint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45