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

[Bug 20266] New: Authentication using Shibboleth - bootstrap
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20266 Bug ID: 20266 Summary: Authentication using Shibboleth - bootstrap Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Bug 12046 stated that CAS authentication is too complex to be displayed in a modal window, therefore authentication is displayed in a separate page when CAS authentication is enabled. However, Shibboleth auth is quite the same as CAS auth in terms of complexity, and yet the modal is still used when Shibboleth authentication is enabled. This doesn't seem like a consistant behavior to me. Shouldn't the modal also be disabled when Shibboleth authentication is enabled? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 34070] New: background_jobs_worker.pl fills logs when not connecting
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34070 Bug ID: 34070 Summary: background_jobs_worker.pl fills logs when not connecting Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I noticed my disk was filling up, because worker-output.log was getting several hundred of these per second: [2023/06/20 18:21:24] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/background_jobs_worker.pl line 116. main::catch {...} /usr/share/koha/bin/background_jobs_worker.pl (119) I think the problem is related to this code: 106 while (1) { 107 if ( $conn ) { 108 my $frame = $conn->receive_frame; 109 if ( !defined $frame ) { 110 # maybe log connection problems 111 next; # will reconnect automatically 112 } 113 114 my $args = try { 115 my $body = $frame->body; 116 decode_json($body); # TODO Should this be from_json? Check utf8 flag. 117 } catch { 118 Koha::Logger->get({ interface => 'worker' })->warn(sprintf "Frame not processed - %s", $_); 119 return; 120 } finally { 121 $conn->ack( { frame => $frame } ); 122 }; 123 124 next unless $args; 125 126 # FIXME This means we need to have create the DB entry before 127 # It could work in a first step, but then we will want to handle job that will be created from the message received 128 my $job = Koha::BackgroundJobs->find($args->{job_id}); There is a problem with the connection, but $conn is still defined, so this code is run. When I Dump $conn after line 107 it looks like this: $VAR1 = bless( { 'bufsize' => 8192, 'logger' => bless( { 'warn' => 1, 'error' => 1, 'fatal' => 1 }, 'Net::Stomp::StupidLogger' ), '_framebuf_changed' => 1, 'port' => '61613', 'connect_delay' => 5, '_pid' => ***, 'hostname' => 'localhost', 'reconnect_attempts' => 0, 'reconnect_on_fork' => 1, 'select' => bless( [ '�', 1, undef, undef, undef, undef, undef, undef, undef, bless( \*Symbol::GEN0, 'IO::Socket::IP' ) ], 'IO::Select' ), 'socket' => $VAR1->{'select'}[9], 'initial_reconnect_attempts' => 1, '_framebuf' => '', 'socket_options' => {}, 'subscriptions' => { 'dest-/queue/koha_***-default' => { 'ack' => 'client', 'destination' => '/queue/koha_***-default', 'prefetch-count' => 1 } } }, 'Net::Stomp' ); If I dump the contents of $body after line 115, I get 'You must log in using CONNECT first'. Not sure why that happens yet, but how we handle it seems to be problematic. We fail to decode it, because it is not JSON. So the "catch" block is run and logs the problem. But then I think the "return" kicks us back to the start of the "while" and we end up logging the same error as fast as we can, which seems to be pretty fast. And we never get to the "ack" on line 121. The comment "will reconnect automatically" seems to be a little optimistic? Moving the "return" from the end of the "catch" block, to the end of the "finally" block slows things down, now the logging only happens about every other second. But there is also a problem because we are assigning the "output" from the try/catch to $args. If we can decode_json the $body, that works as expected. But if we execute the "catch" block, it looks like $args gets assigned the result of Koha::Logger->get, which seems to be 1. So $args is defined on line 124 and we get to Koha::BackgroundJobs->find, but using "1" as a hashref there does not work. I think maybe something like this would work better: my $args; try { my $body = $frame->body; $args = decode_json($body); # TODO Should this be from_json? Check utf8 flag. } catch { Koha::Logger->get({ interface => 'worker' })->warn(sprintf "Frame not processed - %s", $_); } finally { $conn->ack( { frame => $frame } ); return; }; Is the return needed? This is a little above my head, so other solutions are most welcome. And if anyone can tell me why I get 'You must log in using CONNECT first' I would be most grateful. :-) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 27208] New: Add a configurable time delay feature to notice templates
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27208 Bug ID: 27208 Summary: Add a configurable time delay feature to notice templates Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have a configurable time delay feature added to the notice templates. In our case, items with holds are immediately trapped, and the hold notice gets sent, when they get returned through our sorter. However, we are quarantining materials for 72 hours so we don’t want the hold pickup notice sent until the items come out of quarantine. Other possible uses for a configurable time delay might be when one library in a system is quarantining items but another is not. In a consortium, with a mix of school and public libraries, they might want to send notices at different times. Other libraries have mentioned their patrons arrive at the library because they got their pickup notice but staff hasn’t actually had time to process the holds. This would be especially helpful with hold notices but could also apply to other notices. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 34304] New: Use "days in advance" for hold reminder notice
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '26

04 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34304 Bug ID: 34304 Summary: Use "days in advance" for hold reminder notice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment the "days in advance" for the HOLD_REMINDER notice can only be configured via command line options. It would be much nicer if we could use the setting in the messaging preferences (same as for the pre-due notice). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 31930] New: Ignore whitespace before and after barcodes when adding items to rotating collections
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '26

04 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31930 Bug ID: 31930 Summary: Ignore whitespace before and after barcodes when adding items to rotating collections Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: trivial Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When you add items to a rotating collection by copy and pasting the barcode, there will often be whitespace causing a 'barcode not found' error. We should automatically remove/ignore this leading/trailing whitespace as we do in other forms like the checkout/checkin forms. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 28633] New: Add a preferred_name field and an effective_name method to patrons
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '26

04 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 Bug ID: 28633 Summary: Add a preferred_name field and an effective_name method to patrons 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some institutions store legal names in their directories and for patron imports, but would also like to be able to record 'preferred' names in the patro records. It would be nice to have a field for preferred_name and a method to select the preferred name when it exists, and the firstname when it doesn't Following the item we would suggest 'effective_name' - the additional method can be used in patron-title.inc and in notices to simplify name choice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 194

[Bug 32726] New: Authority search result display and relator terms in 22.05
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32726 Bug ID: 32726 Summary: Authority search result display and relator terms in 22.05 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: marius.mandrescu(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 31484] New: Renewals disabled message doesn't display all reasons why something cannot be renewed
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31484 Bug ID: 31484 Summary: Renewals disabled message doesn't display all reasons why something cannot be renewed 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There are many reasons why the renewals-disabled button might display in the issues table but not all of them will display depending on the circumstance, this can hamper librarians ability to make correct choices. For example: 1. Have an item checkout out what can be renewed at least one time BUT make that item overdue. 2. In the renewal column you'll see "0 Not allowed: overdue". That is good. 3. Have 'AllowRenewalOnHoldOverride' set to 'Don't allow' 4. Place the same item from 1-2 on hold. Make it an item level hold on that specific item. 5. Look at the issues table again, it still says "0 Not allowed: overdue". 6. The message should include some language saying the item can't be renewed becuase it is on hold AND it is overdue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 15834] New: Options to supress e-mail generated by AutoEmailOpacUser
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15834 Bug ID: 15834 Summary: Options to supress e-mail generated by AutoEmailOpacUser Change sponsored?: --- Product: Koha Version: unspecified 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 Would love to see a selection when creating a new account to suppress the welcome e-mail generated by AutoEmailOpacUser. Sometimes, like when creating accounts for ILL, you don't want to send the info. It would also be great if there were a preference where you could choose patron groups to not send this e-mail to. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 34994] New: Consider translations in updatedatabase
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '26

03 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34994 Bug ID: 34994 Summary: Consider translations in updatedatabase Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N 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: frederic(a)tamil.fr I wanted to open the discussion on this subject. Currently, when we insert things in the database using db_revs or updatedatabase, the strings are inserted in English. For a lot of things, like database structure changes and that type of stuff, it's fine. But for new letters, authorized values or additional content, it inserts in English no matter what the language of the installation is. That means that when we update Koha, we have to go in and translate all of those new things in the interface. We already translate the strings for new Koha installations through the translation of yaml files. I was wondering if it was somehow possible to use the yaml files and their translations to insert the new values? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9