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

[Bug 30687] New: Unable to override hold policy if no pickup locations are available
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30687 Bug ID: 30687 Summary: Unable to override hold policy if no pickup locations are available Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Set the following settings: Reserves policy by item type for Branch A: Item type: BK Reserve policy: From home library Reserve pickup library match: any library Return policy: Item returns home AllowHoldPolicyOverride: Allow Create a biblio with an item: Item home library: Branch A Item type: BK Log in to the staff client as a Patron that belongs to Branch B. Go to place a hold on the Biblio. Notice that you are blocked because there is no valid pickup location, and unable to override it. Previously we could override this restriction, but we now can't. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52

[Bug 35653] New: Allow the patron import script to log it's output to the action_logs cron logging
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35653 Bug ID: 35653 Summary: Allow the patron import script to log it's output to the action_logs cron logging Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be so neat if the import_patrons.pl command line tool had the option to send the brief output to the in-Koha action_logs cron logs, so at least libraries could see easily that the cron had run. Bonus points for useful info in there like what it currently can output on the command line: Import complete: Imported: 0 Overwritten: 1981 Skipped: 0 Invalid: 0 Total: 1981 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 35564] New: Add homebranch column to holds queue report
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35564 Bug ID: 35564 Summary: Add homebranch column to holds queue report Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Some librarians need to be able to see the homebranch of items in the holds queue report. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 31185] New: Link authorities automatically doesn't detect duplicate authorities
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31185 Bug ID: 31185 Summary: Link authorities automatically doesn't detect duplicate authorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When cataloging a bibliographic record, the template addbiblio.tt has a code to show that there is more than one local match for the entry point (MULTIPLE_MATCH) but the function LinkBibHeadingsToAuthorities never returns that code. This means that when the authority you are looking for is duplicated and you click the "Link authorities automatically", you obtain the following message "No matching authority found." instead of "More than one local match found. Possibly a duplicate authority!" This gives the false impression that the authority doesn't exist. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 35316] New: Add itemcallnumber to holds history page
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35316 Bug ID: 35316 Summary: Add itemcallnumber to holds history page 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 This form currently shows barcode, not call number. Our users would like to have it too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 28899] New: Don't always make = into : for elastic range searching
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28899 Bug ID: 28899 Summary: Don't always make = into : for elastic range searching Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com For range searches, Elastic supports searches for ranges with one end bound, like "pubdate greater than or equal to 2020." Except the phrasing for that would be "pubdate:>=2020." And Koha wants to let us use either a colon or an equals sign after our index name, so it always converts an equals sign in to a colon, which means our query turns into "pubdate:>:2020" and we get an error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 36397] New: Koha/Plugins/authority_hooks.t seems to fail with Elastic
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36397 Bug ID: 36397 Summary: Koha/Plugins/authority_hooks.t seems to fail with Elastic Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See also bug 35536 comment60 # Failed test 'AddAuthority calls the hook with action=create, id passed' # at /kohadevbox/koha/t/db_dependent/Koha/Plugins/authority_hooks.t line 57. # found warning: Cannot determine authority type for record: 1740 at /kohadevbox/koha/Koha/SearchEngine/Elasticsearch.pm line 573. # found warning: Plugin error (Test Plugin): Exception 'Koha::Exception' thrown 'after_authority_action called with action: create, id: 1740' # expected to find warning: (?^u:after_authority_action called with action: create, id: \d+) # Failed test 'ModAuthority calls the hook with action=modify, id passed' # at /kohadevbox/koha/t/db_dependent/Koha/Plugins/authority_hooks.t line 61. # found warning: Cannot determine authority type for record: 1740 at /kohadevbox/koha/Koha/SearchEngine/Elasticsearch.pm line 573. # found warning: Plugin error (Test Plugin): Exception 'Koha::Exception' thrown 'after_authority_action called with action: modify, id: 1740' # expected to find warning: (?^u:after_authority_action called with action: modify, id: 1740) # Looks like you failed 2 tests of 3. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 36077] New: Create separate cookie options for the staff interface
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36077 Bug ID: 36077 Summary: Create separate cookie options for the staff interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: aude.charillon(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 27378 created HTML customizations for CookieConsentBar and CookieConsentPopup. Despite being listed under the OPAC section of the list of display locations when creating the customizations, these are displayed in both the Opac and the staff interface. This is an issue as the staff interface uses different essential cookies and could have different optional ones. We need two separate sets of cookie-related system preferences and HTML customizations: one for the Opac and one for the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 35348] New: Cookie information should be available regardless of whether you are logged in or not
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35348 Bug ID: 35348 Summary: Cookie information should be available regardless of whether you are logged in or not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34793 When CookieConsent is enabled, the 'More information' button prompts a modal that contains details of what cookies are being used and why. This information is then available from the 'Consents' tab for logged in users, but is entirely hidden for users who have accepted/denied cookies but not yet logged in. We should move the cookie consents display out of the 'Consents' tab in the user profile and into a link from a permanent footer at the bottom of the page (next to where language selection appear when enabled would be perfect) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34793 [Bug 34793] We should ship default 'CookieConsentPopup' data that describes our required cookies -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 35346] New: 'Accept essential cookies' should always appear if CookieConsent is enabled
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35346 Bug ID: 35346 Summary: 'Accept essential cookies' should always appear if CookieConsent is enabled Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Right now, if you don't have any CookieConsentedJS cookies defined but do have CookieConsent set to 'require' then you are shown the footer bar with just an 'Accept all cookies' button. This is misleading, the button should be 'Accept essential cookies' as only essential cookies are going to be accepted.. there are no further cookies in 'all'. -- You are receiving this mail because: You are watching all bug changes.

1 20