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

[Bug 26035] New: AutoMemberNum fails on very large cardnumbers
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26035 Bug ID: 26035 Summary: AutoMemberNum fails on very large cardnumbers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: - create a borrower with cardnumber 603628999632182575912 - turn on automembernum - create a new patron, save without a cardnumber - see that your new patron has cardnumber 0 As part of the fixup_cardnumber sub in Patron.pm, we CAST(cardnumber AS SIGNED), which tries to make the cardnumber into a 64 bit integer. Way back in bug 13178, we increased the max length of a cardnumber to 32 characters, which is longer than a 64 bit integer can handle. So the CAST spits out a -1, to which Koha adds 1, arriving at cardnumber 0. Why do we cast it as signed in the first place? I don't understand enough about integers to see what purpose this is serving. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 34729] New: OPACAuthorIdentifiers Unimarc
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34729 Bug ID: 34729 Summary: OPACAuthorIdentifiers Unimarc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Please add to OPACAuthorIdentifiers "MARC21 only" in cgi-bin/koha/admin/preferences.pl?tab=opac#opac_Features In Unimarc "Display" leads to an error. Later I looked in https://koha-community.org/manual/23.05/en/html/opacpreferences.html#opacau…. Good Luck! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 29578] New: Search term highlighting breaks with titles containing characters with Greek diacritics
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29578 Bug ID: 29578 Summary: Search term highlighting breaks with titles containing characters with Greek diacritics Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org The commits from Bug 5844 and Bug 20501 fixed the problem of DOM content disappearing from the results of OPAC/Staff Client searches under certain conditions (e.g. when the search terms were "magaz mag" or "the the"). However, there is still a case where the jQuery term highlighter can break, and in the process actually make the "Highlight"/"Unhighlight" button disappear altogether! To reproduce, catalogue two books using the titles below, one of which includes a word ("τοῖς") [1] containing Greek diacritics: Title #1: Συλλογής των εν επιτομή τοῖς πάλαι γεωγραφηθέντων Title #2: Επιτομή της ιστορίας των Βαλκανικών Πολέμων (1912-1913) Then, perform a catalog search for "επιτομή των" (without the quotes). You should get what is depicted in the attached screenshots. Notice how 1) the "Highlight"/"Unhighlight" button has disappeared, and 2) not all search terms are highlighted (e.g. "των" in the 2nd result) If using Firefox, in the Browser Console the following error will be logged: Uncaught DOMException: Index or size is negative or greater than the allowed amount The offending file is koha-tmpl/opac-tmpl/bootstrap/lib/jquery/plugins/jquery.highlight-3.js, line 26: 26 var endbit = middlebit.splitText(pat.length); Upgrading the plugin from its current version (v3) to the latest version available [1] from the developer (v5) fixes the problem. Please note that the changes to this script from commit 2e4b574074 should also be incorporated. [1] https://en.wiktionary.org/wiki/%CF%84%CE%BF%E1%BF%96%CF%82 [2] https://johannburkard.de/blog/programming/javascript/highlight-javascript-t… -- You are receiving this mail because: You are watching all bug changes.

1 47

[Bug 23520] New: Error: invalid_request using Google OpenID Authentication
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23520 Bug ID: 23520 Summary: Error: invalid_request using Google OpenID Authentication Change sponsored?: --- Product: Koha Version: 17.11 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: gcastellano(a)nosturi.es QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Hi there, We are trying unsuccessfully to connect an instance of Koha 17.11.18.000 to Google OpenID following the instructions provided here: https://koha-community.org/manual/17.11/html/02_administration.html?highlig…. This is the error that we get: 400. That’s an error. Error: invalid_request Invalid parameter value for redirect_uri: Missing scheme: /cgi-bin/koha/svc/auth/googleopenidconnect Learn more Request Details response_type=code redirect_uri=/cgi-bin/koha/svc/auth/googleopenidconnect client_id=151271246332-2rutdao24k2as059d4ht7gmo0utln43l.apps.googleusercont… scope=openid email profile state=auth_660a4a0ed00714e959894abe360a3532 That’s all we know. We have checked that we have a client ID and a client secret; and that the authorized JavaScript origins, as well as the authorized redirect URLs, match the URL of the OPACBaseURL and http://YOUROPAC/cgi-bin/koha/svc/auth/googleopenidconnect <http://YOUROPAC/cgi-bin/koha/svc/auth/googleopenidconnect>. We have also checked that the values of GoogleOAuth2ClientID and GoogleOAuth2ClientSecret in Koha match the values of the Google client ID and the client secret. We are not sure whether we are missing something or there is something wrong in the docs, Koha 17.11 or the connector. Many thanks in advance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27448] New: Update ElasticsearchCrossFields description to explain consequences of setting in Koha
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27448 Bug ID: 27448 Summary: Update ElasticsearchCrossFields description to explain consequences of setting in Koha Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 The description of the ElasticsearchCrossFields is technical correct, but for someone configuring Koha, it's not clear what the settings mean for using Koha. What's the consequence of choosing one setting or the other? It's only clear that you will need to use a specific Elasticsearch version. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 34707] New: Abstract intranet-tmpl/includes/*-search.inc
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34707 Bug ID: 34707 Summary: Abstract intranet-tmpl/includes/*-search.inc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, katrin.fischer(a)bsz-bw.de, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, oleonard(a)myacpl.org, tomascohen(a)gmail.com After looking at bug 34624, I thought we could abstract (thus reducing) a lot of code and, making it more maintainable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 34705] New: Koha should use a CSV library to generate CSV
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '23

06 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34705 Bug ID: 34705 Summary: Koha should use a CSV library to generate CSV Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Generating CSV using a template and concatenating string using separators doesn't always generate valid CSV, and should be a avoided. The Koha codebase shouldn't contain code to deal with special escape sequences or CSV generation internals. We already include Text::CSV_XS and should just pass it arrayrefs for each row, and let the library deal with CSV complexities [1]. This was highlighted by bug 34043. [1] https://en.wikipedia.org/wiki/Comma-separated_values#Basic_rules -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31584] New: Default indicators not taken into account when creating records using UseACQFrameworkForBiblioRecords
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '23

05 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31584 Bug ID: 31584 Summary: Default indicators not taken into account when creating records using UseACQFrameworkForBiblioRecords Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When using UseACQFrameworkForBiblioRecords default indicators are not added to the record as configured in the ACQ framework. For a test: * Create 264 abc in your ACQ framework, set second indicator to default 1 * Create an order using the form * Verify the indicator hasn't been set For some fields where the label shown depends on the indicator, this creates a display issue. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 15504] Track Patron's Last Activity
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '23

05 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 Matt Blenkinsop <matt.blenkinsop(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|33997 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33997 [Bug 33997] Borrowers.updated_on should not be updated by track_login -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34715] New: BiblioItemtypeInfo should hide 942c image on detail when having multiple item type images
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '23

05 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34715 Bug ID: 34715 Summary: BiblioItemtypeInfo should hide 942c image on detail when having multiple item type images 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org If I enable BiblioItemtypeInfo while using item level itypes, the 942c image is displayed on search results. Great! But on the detail pages I would rather hide it when actual item type images are available. Reported this on Templates since it concerns OPAC and Staff. -- You are receiving this mail because: You are watching all bug changes.

1 1