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

[Bug 34818] New: Cannot perform batch patron modification without selecting a patron attribute
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34818 Bug ID: 34818 Summary: Cannot perform batch patron modification without selecting a patron attribute Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com Depends on: 21083 I've been testing batch patron modification while working on Bug 33927 and have found that if I submit a batch of patrons for modification I have to select a patron attribute or the process will fail: Can't call method "category_code" on an undefined value at /kohadevbox/koha/tools/modborrowers.pl line 407 It doesn't appear to matter how the batch is submitted, whether it be cardnumbers, borrowernumbers, or patron list. It looks to me like Bug 21083 is the cause. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21083 [Bug 21083] Batch patron modification does not allow to modify repeatable patron attributes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 34494] New: Table tmp_holdsqueue fails to be created for MySQL 8
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34494 Bug ID: 34494 Summary: Table tmp_holdsqueue fails to be created for MySQL 8 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It appears that MySQL 8 rejects creating any table where the primary key is nullable. The table tmp_holdsqueue has a nullable pk ( itemnumber ) but there is no reason for this column to be nullable ( generating a holds queue entry with no itemnumber is not possible ) so it make sense to just remove the nullability for MySQL compatiability. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 32127] New: Always sort patrpn
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32127 Bug ID: 32127 Summary: Always sort patrpn Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 31077] New: Return claims won't load on details tab, when ClaimReturnedLostValue is empty
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31077 Bug ID: 31077 Summary: Return claims won't load on details tab, when ClaimReturnedLostValue is empty Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When ClaimReturnedLostValue is empty, the tab with the number of open claims will show both on the checkouts and the details tab of the patron account in the staff interface, but on details, nothing will display when the tab is opened. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 19885] New: Allow MaxOpenSuggestions to be set by patron type
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19885 Bug ID: 19885 Summary: Allow MaxOpenSuggestions to be set by patron type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if we could set MaxOpenSuggestions by patron type/library. This would allow each library in a consortium to use the suggestions in the way that was most efficient for each library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 35001] New: Patron->is_active should respect TrackLastPatronActivityTriggers
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35001 Bug ID: 35001 Summary: Patron->is_active should respect TrackLastPatronActivityTriggers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low 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 Depends on: 15504 Bug 33245 beat bug 15504 into Koha.. unfortunately this leads to the new method contained a series of hard coded queries for what the author felt are 'activity'.. Bug 15504 puts this into the hands of the librarians by exposing a preference for listing various actions that should trigger the lastseen update. We should update the is_active method to reduce the hard coded database calls used and utilise the activity stored in lastseen as defined by the Triggers preference. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 [Bug 15504] Track Patron's Last Activity -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 35030] New: Extend TrackLastPatronActivity with place hold and article request
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35030 Bug ID: 35030 Summary: Extend TrackLastPatronActivity with place hold and article request 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com See bug 15504 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 35027] New: Add holds to patron activity triggers
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35027 Bug ID: 35027 Summary: Add holds to patron activity triggers 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 15504 If a staff member submits a hold for a patron, that may be construed as signifying the patron is active. (and may not have been caught by a login or other activity trigger already) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 [Bug 15504] Track Patron's Last Activity -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 30043] New: Malformed records shown as not existing
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30043 Bug ID: 30043 Summary: Malformed records shown as not existing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org I just had a case where a batch MARC import script (not part of Koha, but maintained separately) had put some records with an empty 942 field into the database. The MARCXML looked something like this: <datafield tag="887" ind1=" " ind2=" "> <subfield code="a">x</subfield> </datafield> <datafield tag="942" ind1=" " ind2=" "> </datafield> <datafield tag="950" ind1=" " ind2="k"> <subfield code="a">y</subfield> </datafield> When trying to view these records, the following message was displayed: The record you requested does not exist But all the data were in the biblio, biblioitems, biblio_metadata tables. It was not possible to view the the record in the editor either. Would it be possible to catch this error and say something like "The record you requested has fatal errors" instead of telling the user it does not exist? Relevant code in catalogue/detail.pl: 78 my $record = GetMarcBiblio({ biblionumber => $biblionumber }); 79 my $biblio = Koha::Biblios->find( $biblionumber ); 80 $template->param( 'biblio', $biblio ); 81 82 if ( not defined $record ) { 83 # biblionumber invalid -> report and exit 84 $template->param( unknownbiblionumber => 1, 85 biblionumber => $biblionumber ); 86 output_html_with_http_headers $query, $cookie, $template->output; 87 exit; 88 } This reports unknownbiblionumber => 1 when $record is not defined, but it does not differentiate between "biblionumber does not exist" and "biblionumber points to a broken MARCXML record". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 32396] New: CMS page default language link should still allow to the change language
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '23

01 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32396 Bug ID: 32396 Summary: CMS page default language link should still allow to the change language Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pascal.uphaus(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Test plan: 1. Install a second language to the koha instance 2. Enable the language via the systempreferences (language, OPAClanguages and opaclanguagesdisplay) 3. Adding a page via koha-domain/cgi-bin/koha/tools/additional-contents.pl?category=pages 4. added the translations default, english and the second language 5. Opening the default link for OPAC or for the Staff Interface 6. Change the Language and go back to the same url and reload the page. 7. Result: the language of the opac is still the default one Is this intended that the Link always resets the language to the default language, when accessing the page via link or go back and reload the page? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5