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

[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

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

30 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 27992] New: when recording local use with STAT patron items are not checked in
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27992 Bug ID: 27992 Summary: when recording local use with STAT patron items are not checked in Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When recording local use using a statistical patron, the Lost status updates, but if an item is checked out, it does not get checked in. To replicate: 1. Create a Statistical Patron 2. Check out an item to the Stat Patron, that is checked out to another user 3. See that the local use is recorded, but the item does not get checked in 4. Check out an item that has a lost status and note that the local use is recorded, and the lost status is cleared In this situation, the item should be checked in/available status updated when it is "checked out" to the statistical patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 25530] New: Web installer font size too small to read on some screens
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25530 Bug ID: 25530 Summary: Web installer font size too small to read on some screens Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This may be subjective as I'm on a FullHD (1920x1080) laptop screen, but I noticed that the Web Installer font size is a bit too small to read. To be more specific, v18.11.16 is the last version where the body font-size property is set to 14px in bootstrap.min.css. From v19.05.00 onwards the size decreased to 12px and this makes the textual elements (including the button labels) appear a bit too small, and are harder to read compared to previous Koha versions. Please view the attached screenshots for a side-by-size comparison. I think this may be related to Bug 22023. Possibly relevant excerpt from commit a344b8cf8c: "The modified default CSS resets the base font size in Bootstrap to better match our global CSS. A side-effect of this is that toolbar buttons ended up looking smaller than they should. Changing the button class solves this." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 18983] New: koha-create does not default to --create-db
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18983 Bug ID: 18983 Summary: koha-create does not default to --create-db Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: CJSH(a)CJSHayward.com QA Contact: testopia(a)bugs.koha-community.org I reported in an email on the list that, after clearing away previous and possibly conflicting material, I found a .in file in /etc but didn't see how to make an appropriate koha-conf.xml. The reply I received was that there was apparently an issue that "koha-create library" should, by default, behave as if "koha-create --create-db library" had been entered. However, it did not. When I ran "koha-create --create-db library" it worked further and populated /etc/koha/sites/library with several configuration files. N.B. I got further, but I do not yet have a real site (attempting to configure the webinstaller gets redirected to a maintenance mode page at /cgi-bin/koha/maintenance.pl); however, that may be a separate issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27234] New: Indicate if item is reserved when loaning to localuse patron
by bugzilla-daemon＠bugs.koha-community.org 29 Jan '25

29 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27234 Bug ID: 27234 Summary: Indicate if item is reserved when loaning to localuse patron 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the statistical patron to record localuse, there are no indications whether the items is reserved or already on loan. To test: 1) In Administration > Patron categories > New category, create a category called Local use and make sure to choose the Category type 'Statistical' 2) Go to Patrons > New patron and create a Local use patron 3) Place a hold on an item 4) Check out the item to the statistical local use patron --> Message says 'local use recorded' It would be nice if the system could alert the staff that the item is on hold while they have the item in hand. Otherwise, they shelve it and they have to get it again when they check the holds to pull list. In comparison, when using the checkin system to record local use, with RecordLocalUseOnReturn, the hold pop-up appears with the message 'local use recorded' also. Another comparison, if you try to check out an item that has a hold to another patron, the system will alert you that there is a hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2