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

[Bug 31676] New: Fix db_dependent/Circulation.t tests
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31676 Bug ID: 31676 Summary: Fix db_dependent/Circulation.t tests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A lot of tests in db_dependent/Circulation.t are currently failing, many seems to have done so for quite a while so it's a bit puzzling how this has gone under radar for such a long time. If any of the changes are unclear I'm happy to expand more on the different addressed issues. A short summary of the changes: - The patron attribute autorenew_checkouts was added a while ago, patrons for some tests needed this set to preserve previous behavior - OverduesBlockRenewing-test relied on a state that was mutated by new tests, these have been moved to a place where the state is as was before this regression. - The test "AddRenewal left both fines" broke when account line statuses where refactored (probably), there should be one one fine - Fixed a test which expects 'auto_to_soon' error. CanBookBeRenewed will not return this status unless the $cron parameter is set to true - "Incremented fee tests" builds an item with missing "library" parameter since treating the library object as a hashref. This cases a circulation-rule not match and serveral tests fail as a result. - The "AddIssue records staff who checked out item if appropriate" subtest treats some objects as hashrefs when retrieving properties, and also checks the wrong issue objects in the last test. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 32916] New: [Bug 30280 follow-up] Problems in linking authorities to biblio fields (MARC 21)
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32916 Bug ID: 32916 Summary: [Bug 30280 follow-up] Problems in linking authorities to biblio fields (MARC 21) Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frank.hansen(a)ub.lu.se, katrin.fischer(a)bsz-bw.de I encounter two problems connected to recent changes in the Linker module: 1. Problem with thesaurus in biblio fields different than 6XX (Zebra and ES) a) The search for a needed authority record (in C4::Heading::_search) is made now not only with the search form derived from controlled field content, but also with the second operand – the thesaurus. The second operand is added when $self->{thesaurus} is defined. And at the current for MARC 21 it is always defined (C4::Heading::MARC21::parse_heading returns the right thesaurus symbol for 6XX fields and ‘lcsh’ for the rest, e.g. 1XX, 7XX, 8XX). b) So, if $self->{thesaurus} ide defined (= always), the thesaurus operand in authority search is determined by examining the second indicator of the field in the bibliographic record. (I leave apart the discussion of why it is taken from the internal structure of the MARC::Field object while $self->{field}->indicator(‘2’) would be the correct way). But the second indicator makes sense – in terms of thesaurus – only for fields 6XX. For other controlled fields it is either undefined or has completely different meaning (e.g. in 700, 710, 711, 730, 830 etc.). The c) So, in C4::Heading::_search we should consider the thesaurus operand only for 6XX fields. This could be done either by checking $self->{field}->tag in C4::Heading::_search or by not defining $self->{thesaurus} in C4::Heading::MARC21::parse_heading for fields != 6XX. 2. Problem with thesauri in Zebra searches a) While preparing Zebra indexes for authorities (authority-zebra-indexdefs.xsl), the 008/11 byte or authority record is transformed from one character code to the symbol (a => lcsh, b => lcac, etc.). b) But in C4::Heading::_search the thesaurus operand is formulated as one character code conforming to the auth 008/11 convention. As a consequence, no results are returned (unless by accident). c) A possible solution could be removing the transformation (authority-zebra-indexdefs.xsl, koha-indexdefs-to-zebra.xsl) while generating Zebra index or refactoring the thesaurus fragment in C4::Heading::_search to reflect this duality in recording information in indexes (Zebra vs. ES). Could anybody confirm that the problems occur in other installations? Cheers! - Janusz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 31497] New: When you forget to fill in a field of the patron quick_add_form during a 1st validation test, the field, even if completed, is no longer saved
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31497 Bug ID: 31497 Summary: When you forget to fill in a field of the patron quick_add_form during a 1st validation test, the field, even if completed, is no longer saved Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com After filling it in, the 2nd attempt is not blocked, the validation can be done, but it seems that the field is cleared just before submission. Olivier Crouzet -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 29303] New: quick add form duplicates HTML ID's
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29303 Bug ID: 29303 Summary: quick add form duplicates HTML ID's Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons 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 We noticed while trying to add some jQuery to the quick add from that there are duplicate id's on the page for each input. The jQuery on memberentrygen.tt checks to see what fields should be present on the quick_add_form and then uses jQuery clone() to add them to the quick_add_form. The problem is this creates duplicate ID's which is invalid HTML. We should change those cloned ID's so they are not duplicates. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 30978] New: Potential data loss when using Quick add new patron
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30978 Bug ID: 30978 Summary: Potential data loss when using Quick add new patron 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: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the Quick add new patron form with mandatory fields, if a mistake is made, data can be lost. To replicate: - In System Preferences, go to: BorrowerMandatoryField - Put in some mandatory fields - e.g. firstname, surname, cardnumber - Go to Patrons - Press +Quick add new patron - Choose patron as a category type - Note that firstname, surname and cardnumber are all mandatory fields - Put data into firstname and cardnumber - Do not put any data in surname - Press Save The form will not submit because surname is a required field - and a prompt is shown: "This field is required." - Now correct your mistake and fill in the surname - Press Save - The form now submits and creates an account - but the corrected surname field is still blank I've tested this with a range of fields - and I've added 10 mandatory fields and submitted a form with 2, then corrected 4, then submitted again etc - and the form always sends the very first version and disregards any amendments. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 30590] New: Add option for using AutoSelfCheckID and AutoSelfCheckPass values to log into OPAC self check-in module
by bugzilla-daemon＠bugs.koha-community.org 04 May '23

04 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30590 Bug ID: 30590 Summary: Add option for using AutoSelfCheckID and AutoSelfCheckPass values to log into OPAC self check-in module 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be useful if all patrons, regardless of whether they have the self_checkin_module sub-permission enabled, could check items in using the OPAC self check-in module. This could be achieved by adding a syspref allowing libraries to choose if the Koha patron defined in the AutoSelfCheckID and AutoSelfCheckPassw sysprefs can log into the self check-in module. We want this so that it can be an option to add behaviour that mirrors the self check-out. Currently, the patron in the AutoSelfCheckID and AutoSelfCheckPass sysprefs can only be used to log into the self check-out module. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 30472] New: Field borrower_relationships.guarantor_id should be marked as NOT NULL
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30472 Bug ID: 30472 Summary: Field borrower_relationships.guarantor_id should be marked as NOT NULL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See also $DBversion = '19.06.00.022'; CREATE TABLE `borrower_relationships` [...] guarantor_id INT(11) NOT NULL, guarantee_id INT(11) NOT NULL, Many production db's will have both fields already NOT NULL. We need to adjust kohastructure and DBIx Note that non-patron guarantors are NOT saved in this table but in the borrowers table itself IIUC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 32279] New: GetAuthorizedHeading missing from exports of C4::AuthoritiesMarc
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32279 Bug ID: 32279 Summary: GetAuthorizedHeading missing from exports of C4::AuthoritiesMarc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org C4::AuthoritiesMarc method GetAuthorizedHeading is not exported thus it is called in other modules : > git grep GetAuthorizedHeading C4/AuthoritiesMarc.pm:=head2 GetAuthorizedHeading C4/AuthoritiesMarc.pm: $heading = &GetAuthorizedHeading({ record => $record, authid => $authid }) C4/AuthoritiesMarc.pm:sub GetAuthorizedHeading { C4/Breeding.pm: $heading = C4::AuthoritiesMarc::GetAuthorizedHeading({ record => $marcrecord }); C4/ImportBatch.pm: $row->{'authorized_heading'} = C4::AuthoritiesMarc::GetAuthorizedHeading( { authid => $row->{'candidate_match_id'} } ); C4/ImportBatch.pm: my $authorized_heading = C4::AuthoritiesMarc::GetAuthorizedHeading({ record => $marc_record }); It should be exported. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 32280] New: Export method ImportBreedingAuth from C4::Breeding
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32280 Bug ID: 32280 Summary: Export method ImportBreedingAuth from C4::Breeding Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In C4::Breeding method ImportBreedingAuth() should be exported to be used for example by plugins. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 31259] New: Downloading patron card PDF hangs the server
by bugzilla-daemon＠bugs.koha-community.org 03 May '23

03 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31259 Bug ID: 31259 Summary: Downloading patron card PDF hangs the server Change sponsored?: --- Product: Koha Version: 21.11 Hardware: PC OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Hi, One of our customers is having an issue with their patron card creator, that we have been able to replicate on our support server. Both installations are Debian package installations, and both installations run atop Debian 10. When one goes to create a 'patron card' using the build-in patron card creator found under Tools > Patron card creator, the download process loops endlessly and eventually returns a Proxy Timeout (we have tried without Plack). Steps to reproduce: 1. Create printer profile with: * 0mm x 0mm offset * 0mm x 0mm creep 2. Create card template with: * 297mm x 210mm page * 99.1mm x 38.1 card * 15mm top page margin * 5mm left page margin * 2 columns * 7 rows * 3mm gap between columns * 0mm gap between rows 3. Create layout with: * Guide box on * Guide grid off * Field 1 text to 'Name: <firstname> <surname>' * Font to 'Courier' * Font size to 14pt * Text alignment to left * Lower left X co-ord to 20mm * Lower left Y co-ord to 25mm * Print card number as barcode: yes * Lower left X co-ord: 30 * Lower left Y co-ord: 10 * Barcode type: CODE39 * Print card number as text under barcode: yes 4. Add two patrons to a new card batch, and use the previously created printer profile, card template, and layout. 5. Export the entire batch as a PDF. 6. The software will hang, and a 'create-ptf.pl' process will run indefinitely koha@demo1:~$ sudo ps aux | grep perl support+ 30344 93.1 5.2 287880 210820 ? R 10:06 0:05 /usr/bin/perl /usr/share/koha/intranet/cgi-bin/patroncards/create-pdf.pl The create-ptf.pl script eats the CPU, and also appears to leak memory indefinitely, until the OOM killer is forced to step in. I have tried changing a few different values, including the font (as I thought maybe it was Courier being missing in Linux), all to no avail. If anyone has the time to take a look at this, or has a vague idea of what lines to look at so I can see if I can fix it myself, that would be hugely appreciated. Many thanks, Jake -- You are receiving this mail because: You are watching all bug changes.

1 32