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

[Bug 36401] New: Re-think use of "N/A" in ILL module
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36401 Bug ID: 36401 Summary: Re-think use of "N/A" in ILL module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I just stumbled on that string again and I'd like us to check if we couldn't do better: * We don't use it in any other module in Koha but ILL, but there a lot * It often poses a problem in translations as people are not aware what it means -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 36551] New: Ability to alert library staff when new ILL requests are placed
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36551 Bug ID: 36551 Summary: Ability to alert library staff when new ILL requests are placed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucy.vaux-harvey(a)ptfs-europe.com CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com For libraries that do not have dedicated interlibrary loan staff it is useful for staff to be alerted when a new request needs actioning. Staff can currently be alerted to cancelled and modified requests via the notices ILL_REQUEST_CANCEL and ILL_REQUEST_MODIFIED but not for new requests. There is a similar feature is available for holds by enabling the system preference emailLibrarianWhenHoldisPlaced. An alternative would be to highlight new ILL requests on the homepage dashboard in a similar way to purchase suggestions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23187] New: Koha::Objects supports find_or_create without passing through the Koha::Object store method
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23187 Bug ID: 23187 Summary: Koha::Objects supports find_or_create without passing through the Koha::Object store method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P1 - high Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, jonathan.druart(a)bugs.koha-community.org, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 21761 Blocks: 23185 Target Milestone: --- +++ This bug was initially created as a clone of Bug #21761 +++ If we're adding triggers at the code level all over the place by overloading the store method we need to never ever let dbic handle it.. by allowing directly passing data to dbic's find_or_create method in Koha::Objects we are exposing ourselves to places in the codebase skipping the store triggers. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21761 [Bug 21761] Koha::Object supports passing through 'update' which means we can side step 'set' + 'store' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23185 [Bug 23185] Koha::Objects supports passing through 'update' which means we can side step 'set' + 'store' -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. You are watching all bug changes.

1 8

[Bug 32747] New: OPAC detail page explodes for items without itemtype
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32747 Bug ID: 32747 Summary: OPAC detail page explodes for items without itemtype Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 When there is an item without itemtype the OPAC detail page explodes: Error trace Can't call method "itemtype" on an undefined value at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 713 I know we agreed not to fix this everywhere, but I think there is definitely a need to fix it in this very spot, because it's on a main page in the OPAC. One thing that can cause this: We just very recently made itemtype mandatory on the acq item form. On order items often had no itemtypes in the past and it was not a problem. Libraries would assign the itemtype on delivery/receive, avoiding any issues in circulation. There might be quite a lot of those 'in the wild'. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 20826] New: Error during initial setup
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20826 Bug ID: 20826 Summary: Error during initial setup Change sponsored?: --- Product: Koha Version: master Hardware: PC OS: Linux Status: NEW Severity: blocker Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: mrushizha(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org I am new to both Linux and Koha. I have been trying to install Koha on a new installation of Ubuntu Linux 16.04.4 LTS Desktop 32-bit. I ran the following preparation commands without any problem: sudo apt-get update sudo apt-get upgrade sudo echo deb http://debian.koha-community.org/koha stable main | sudo tee /etc/apt/sources.list.d/koha.list sudo wget -O- http://debian.koha-community.org/koha/gpg.asc | sudo apt-key add - sudo apt-get update sudo apt-get upgrade sudo apt-get clean I ran the install command and I never got passed it: sudo apt-get install koha-common All I am getting is the following: diasha@DIASHA-UBUNTU:~$ sudo apt-get install koha-common [sudo] password for diasha: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: koha-common : Depends: libnet-oauth2-authorizationserver-perl but it is not going to be installed E: Unable to correct problems, you have held broken packages. I have Googled this and and I also did a clean re-installation of Ubuntu and tried to install Koha to no avail. I am looking forward to your response. Regards, Michael -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 24119] New: Records indexed into ES during tests are not removed by rollback
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24119 Bug ID: 24119 Summary: Records indexed into ES during tests are not removed by rollback Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If SearchEngine is set to Elasticsearch we index bibs directly into the engine. This means that a rollback won't remove these records. Zebra only indexes from the zebraqueue which is in DB so is protected by transactions -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 28199] New: MARC framework CSV and ODS import incomplete or corrupted - part 2
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28199 Bug ID: 28199 Summary: MARC framework CSV and ODS import incomplete or corrupted - part 2 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Test plan 1 1. Export default MARC framework in CSV 2. Open the .csv with LibreOffice and save it 3. Create a new framework 4. import the CSV 5. See MARC structure of the new framework 6. Tags are missing the trailing zeros (10 instead of 010) 7. View subfields of tag 10/010 8. Compare with default framework 9. Subfields are missing note, why does on the default framework, these two URLs don't yield the same result? /koha/admin/marc_subfields_structure.pl?tagfield=010&frameworkcode= /koha/admin/marc_subfields_structure.pl?tagfield=10&frameworkcode=3 It would also make sense that 10 doesn't yield anything. 10. Same with 031/31 default framework still has different output for 31 and 031 Test plan 2 1. Export default MARC framework in .ods 2. Open the .ods with LibreOffice 3. Save it 4. Create a new framework 5. import the .ods 6. See MARC structure of the new framework 7. View subfield of tag 010 8. Compare with default framework 9. See Also: 4, and Link:4 have appeared (the code of my new framework code is 4) Testing notes: Tags with a lot or diverse subfields: 010 100 240 995 031 110 600 700 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 22462] New: Crash in patron card printing
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22462 Bug ID: 22462 Summary: Crash in patron card printing Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Patron card printing: Layout: the entered text in a text field is longer then the possible page height, page width, card height and card width in the template. Result: when running a batch, the created pdf can't be opened, and Koha doesn't respond. It also seems to end in an infinite loop. It also happens if all values in the template are saved with the default values "0". Template: page height: 50 mm page width: 20 mm card heigh: 50 mmm card width: 20 mm Layout: Textfield Text: Libraries are great -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 24779] New: Shibboleth login url double encodes "=" in query
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24779 Bug ID: 24779 Summary: Shibboleth login url double encodes "=" in query Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: hannah.co(a)northwestu.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org login_shib_url and logout_shib use _get_return to process a url and parameters. I am seeing urls come through with the "=" between the parameter name and the query encoded to "%3D". I think this is because url encoding is done on line 214 to the whole parameter string after assembly. 214 return $uri_base_part . URI::Escape::uri_escape_utf8($uri_params_part); I believe only the query part of the parameter should be uri escaped, on line 209: 209 $uri_params_part .= $uriPiece; My installation with shibboleth login works with lines 209 and 214 changed as follows: 209 $uri_params_part .= URI::Escape::uri_escape_utf8($uriPiece); 214 return $uri_base_part . $uri_params_part; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22497] New: '0' width can lead to an infinite loop.
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22497 Bug ID: 22497 Summary: '0' width can lead to an infinite loop. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- > > "Aha... it's the parentheses which are the problem. They're being interpreted as > > regex metacharacters and not literal values!" > > We noticed that there seems to be an infinite loop if the template has some > or all entries with "0" in it (like in default when creating a new > template). Could this be the same cause? Sorry, I just realized that you were referring to the template rather than the layout. Yes, it would be a related problem, but a separate issue. If 'label_width' is 0, then $self->{'width'} will be 0. That means that this condition will be triggered: if (($string_width + $text_attribs->{'llx'}) > $self->{'width'}) And because $self->{'width'} is 0, then the following condition would never feasibly be triggered: if (($string_width + $text_attribs->{'llx'}) < $self->{'width'}) And this condition is the only thing that can stop the infinite loop. Really the line wrapping code looks like it would benefit from a re-write. -- You are receiving this mail because: You are watching all bug changes.

1 10