March 2026 - Koha-bugs - lists.koha-community.org

[Bug 40159] New: When modifying a subscription with received issues, prediction pattern doesn't start from next issue date
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40159 Bug ID: 40159 Summary: When modifying a subscription with received issues, prediction pattern doesn't start from next issue date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To reproduce the issue : Make a record and create a subscription for this record with a week or month subscription length and a first issue date in the past (like 2016). Receive at least one issue. Edit the subscription and test the prediction pattern. The displayed prediction shows only one number (unless you set the subscription length for like a thousand issues). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 33276] New: Library limitations will cause data loss when editing serials
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33276 Bug ID: 33276 Summary: Library limitations will cause data loss when editing serials Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello @ll, This bug can be related to 31422 and 32748. That's the same behavior on "Locations" dropdown list for serials. When a value is limited to a library if we're logging with a patron from another lib, the location value is empty and can be replaced. I copied the same logic as the submitted patch for 32748. We can modify the value but the current value (provides from another lib) stay in dropdown. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[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 41375] New: Tool to generate a default privacy policy document
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41375 Bug ID: 41375 Summary: Tool to generate a default privacy policy document Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org It would be nice to ship a default privacy policy document with Koha. It could be a configurable tool where superlibrarians could 1. check checkboxes for the types of data they are collecting in Koha 2. include the values of *Log system preferences 3. include templates from privacy regulations, such as GDPR, or national legislation (you could select which template to add) 4. define the durations of data collection (it would be nice to be able to read the triggers of cleanup-database.pl and other cronjobs, but this shouldn't be a blocker for this Bug) 5. document the use of cookies https://wiki.koha-community.org/wiki/Use_of_Cookies The tool would come with prewritten templates, but they should also be modifiable. Something like we currently have with notice templates. -- You are receiving this mail because: You are watching all bug changes.

1 1

[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 41722] New: Argument "" isn't numeric in numeric gt (>)... warnings in opac-detail.tt
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41722 Bug ID: 41722 Summary: Argument "" isn't numeric in numeric gt (>)... warnings in opac-detail.tt 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: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org The warning: [WARN] Argument "" isn't numeric in numeric gt (>) at /kohadevbox/koha/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt line 1578. appears in the plack-opac-error.log. It is quite strange because warning only appears when opac-detail.pl is used for very first time to show record. To reproduce: 1a. Use a fresh KTD or 1b. edit opac-detail.tt (save an insignificant change, like add a space) and restart plack. 2. Observe plack-opac-error.log. 3. Go to any bibliographic record with items in OPAC., e.g. search for "Perl template toolkit". ==> Warnings should appear in plack-opac-error.log ==> (as many as there are items). 4. Restart plack 5. Back to OPAC and refresh view of bibliographic record. ==> No warnings appear. 5. Repeat 1b., 4. and 5. ==> Warnings appear. It seems that check of existens "item_level_holds" is needed before using it in IF condition, but I can't find why warning appers in log only once, not every time when "item_level_holds" is checked in IF. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 41756] New: RSS feed validation
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '26

03 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41756 Bug ID: 41756 Summary: RSS feed validation 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: nicolas.hunstein(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When I perform a search in Koha, click on the RSS feed button, copy the generated string and then validate it on the page: https://www.rssboard.org/rss-validator/, I get the message: "It looks like this is a web page, not a feed. I looked for a feed associated with this page, but couldn't find one. Please enter the address of your feed to validate." Could this please be fixed? We suspect that there is a problem with the content type. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 41736] New: Move IntranetNav to HTML customizations
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '26

02 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41736 Bug ID: 41736 Summary: Move IntranetNav to HTML customizations Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org It would be nice if IntranetNav system preference was moved to HTML customizations. It would allow for example translations to different languages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1