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

[Bug 38835] New: filters on ERM report results are not working
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38835 Bug ID: 38835 Summary: filters on ERM report results are not working Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Created attachment 176163 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176163&action=e… capture filters on ERM report results are not working. And a global search seems to be stuck See capture, after a TR_J1 report (note they are a lot of other reports already loaded in database, maybe the cause for the issue?) -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 38937] New: Password must contain at least characters
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38937 Bug ID: 38937 Summary: Password must contain at least characters Change sponsored?: --- Product: Koha Version: 24.11 Hardware: PC OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: judithjoni(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 176859 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176859&action=e… i tried more then 50 time same error is showing faceign this issue Password must contain at least characters. unable to finish onboarding Web installer › Create Koha administrator patron tried several password not working -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39000 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39000 [Bug 39000] "Encoding errors" block on detail page hurt the eyes -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 38996] New: Add API endpoint for export tool
by bugzilla-daemon＠bugs.koha-community.org 30 Jan '25

30 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38996 Bug ID: 38996 Summary: Add API endpoint for export tool Change sponsored?: --- Product: Koha Version: Main 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 I'm proposing adding an API endpoint for the export tool. This would allow API consumers to export bib records, auth records, DB backups, and conf backups - if appropriately configured. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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

[Bug 38226] New: Add RPC endpoint for batch filling empty callnumbers
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38226 Bug ID: 38226 Summary: Add RPC endpoint for batch filling empty callnumbers Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com Originally proposed on bug 34784, I'm moving the patches here to ease readability and have a smaller testing scope. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 38995] New: Allow to pick an accent color
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38995 Bug ID: 38995 Summary: Allow to pick an accent color Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Style guide Assignee: oleonard(a)myacpl.org Reporter: pablo.bianchi(a)gmail.com QA Contact: martin.renvoize(a)ptfs-europe.com Following Lucas Gass advice on bug 37054#c51; related to bug 31327 and 38550: Right now we can change accent-color by changing hex values on a set of files (CSS/JSON/SVG). #408540 #006100 #418940 #418A40 #589D43 to a dark color (the difference on very similar shades of green seems to be a bug), and #6faf44 #71b443 #7cbb51 #dcefd0 to a light color. By default, using HSL model, the koha's green is around hsl(120, 40%, 40%). I would love to see a syspref to change that hue from 120 to any 0-255 value (or a nicer picker). This would apply to staff and OPAC, and could be overridden by a per library field or custom CSS. Not sure if this could be done independently of a per-user light/dark mode switch (bug 38550). -- You are receiving this mail because: You are watching all bug changes.

1 0