November 2025 - Koha-bugs - lists.koha-community.org

[Bug 40714] New: cookieConsent: current approach arguable on public computers or shared devices
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40714 Bug ID: 40714 Summary: cookieConsent: current approach arguable on public computers or shared devices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Since we just save a simple key in localStorage, this may still be active on public computers for the next user of that computer? Unless they have separate guest accounts, or cookies and localStorage are cleared when the browser exits. Should we make a difference between browsing anonymous or logging in to Koha within this context of public computers? If so, we might need to save data in the db instead of locally? Looks like this report is less clear than the two others (40712 and 40713). -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 40713] New: cookieConsent: key should have an expiration date
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40713 Bug ID: 40713 Summary: cookieConsent: key should have an expiration date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Currently, the created localStorage key cookieConsent does not expire. This needs adjustment in view of following information: "The GDPR does not specify a fixed time limit for cookie expiry; instead, the duration must be proportionate to the cookie's purpose and never exceed 12 months according to the ePrivacy Directive, which requires consent renewal at least annually, and potentially more frequently based on your local Data Protection Authority's (DPA) guidelines, like the six-month recommendations from the Irish DPC and French CNIL." -- See e.g. https://gdpr.eu/cookies/ "If you use a cookie to store a record that a user has given consent to the use of cookies, you should ask the user to reaffirm their consent no longer than six months [*] after you have stored this consent state. (Footnote: While the legislation does not prescribe a specific lifespan for such cookies, based on a first-principles analysis by the DPC, we consider this to be the appropriate default outer timeframe for storing the user’s consent state. A controller would need to objectively and on a case-by-case basis justify storage for a longer period.)" -- Data Protection Commission [Ireland] Since localStorage has no expiration mechanism itself, we could simply add e.g. a unix timestamp as value here. Since the key now contains empty string and is tested for null to check status. This check would become: does the key exist and is its value still in future? A reject removes the key or clears it. Would it be possible to add the expiry period to a preference or enclosed in CookieConsentedJS somehow? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 40712] New: cookieConsent: Accepting essential cookies is unneeded/misleading
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40712 Bug ID: 40712 Summary: cookieConsent: Accepting essential cookies is unneeded/misleading Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org It feels a bit strange to Accept essential cookies. If you dont accept, they work anyway. And if you can accept, you would expect a reject either. But you cant reject them: they are essential and the code just uses them. If there are no additional non-essential cookies, it feels like the bar just needs a OK button to dismiss a message that there are only essential cookies. (This dismissal is not an accept.) "Under GDPR, essential (or strictly necessary) cookies are exempt from requiring user consent because they are fundamental for basic website functionality." -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 41291] New: Add ability to have multiple self registration forms
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41291 Bug ID: 41291 Summary: Add ability to have multiple self registration forms Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries require multiple self registration forms with different visible fields and different required fields. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 38196] New: Filter out concerns by specific status does not include concern without status
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug ID: 38196 Summary: Filter out concerns by specific status does not include concern without status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35628 You can filter out concerns by status (ie. linked with TICKET_STATUS AV). But if you use this "Filter" link on top of the page to remove the concerns with this specific status, it will also remove the concerns without a specific status. concern 1 | Open concern 2 | Resolved concern 3 | status_1 concern 4 | status_2 "Filter status_1" should remove concern 3 only. However it will only show concern 4. This is because the query is ([-and => {status => { '!=' => "status_1" }}]) And does not include status that are NULL in DB. use Koha::Tickets; my $t = Koha::Tickets->search; say $_->status // "undefined" for $t->as_list; say "==="; $t = Koha::Tickets->search([-and => {status => { '!=' => "status_1" }}]); say $_->status for $t->as_list; undefined undefined status_1 status_2 === status_2 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add optional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 35142] New: Koha::Util::oclc_number should be removed in favor of Koha::Biblio::Metadata::Extractor
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35142 Bug ID: 35142 Summary: Koha::Util::oclc_number should be removed in favor of Koha::Biblio::Metadata::Extractor Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 30678, 34828 See bug 34828. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30678 [Bug 30678] Add OCLC_NO as option to OPACSearchForTitleIn https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34828 [Bug 34828] Add Koha::Biblio::Metadata::Extractor* classes -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 39829] New: SIP2 title field does not include subtitle, part or number
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39829 Bug ID: 39829 Summary: SIP2 title field does not include subtitle, part or number Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When returning item info we only include the main 'title' field - for check-in machines this can be unclear when a patron is returning multiple volumes of a series or other items that may share parts of a title. It would be nice to have the option to return full title info -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 37680] New: inconsistencies with the search results when selecting the "Limit to records with available items" option
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37680 Bug ID: 37680 Summary: inconsistencies with the search results when selecting the "Limit to records with available items" option Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org There seem to be inconsistencies with the search results when selecting the "Limit to records with available items" option, when we have a notice with two items if the first item is «notforloan» and the second is «notforloan» too or «withdrawn» the notice is still available. And these conditions also are showing : Case : 1- Record with first item as «notforloan» - The second is «notforloan» 2- Record with first item as «notforloan» - The second is «withdrawn» 3- Record with first item as «itemlost» - The second is «notforloan» 4- Record with first item as «itemlost» - The second is «withdrawn» 5- Record with first item «onloan» - The second is «notforloan» 6- Record with first item «onloan» - The second is «withdrawn» To reproduce: 1. Catalog a new record (record test 1) 1.1. Go to Cataloging 1.2. Click New record 1.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 1.4. Click Save (No need to add an item) 1.5. Add two items, set a negative notforloan (ordered) for the two items 2. Repeat step 1, by creating a record (record test 2) with two items one negative notforloan item and the second as «withdrawn» item 3. Repeat step 1, and creating all the record in «Case» section 4. Go to the Opac and search for the created record 5. Click on «Limit to records with available items» ----> All the created items is still showing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 34488] New: Import default framework
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34488 Bug ID: 34488 Summary: Import default framework Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: viliam.polonec(a)snk.sk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I am testing 23.05.01 version, so we can update our production ILS. I found that I can't import default framework for bibliographic records. I tried export it and import. But with no success. KOHA shows MARC Framework for default MARC framework Create framework for () using selector with frameworks After that nothings changed I test it on two different instalations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 24807] New: Add "year" type to improve sorting by publication date
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24807 Bug ID: 24807 Summary: Add "year" type to improve sorting by publication date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com When sorting on date-of-publication (a year, field 008, positions 7-10), the current behavior when the field contains an invalid year (containing word characters like "uuuu" or just whitespace), these results appear first when sorting in descending order. Invalid values like these should really not be indexed at all. If so (having null values instead) they will always appear last when sorting, regardless of sort order. This fix adds a "year" search field type, that will reject any non-year values, resulting in a more user friendly sorting behavior. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 70