[Bug 39206] New: Koha improperly tries to remove foreign cookies on logout (and in general the cookies aren't actually removed, but set to empty values)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Bug ID: 39206 Summary: Koha improperly tries to remove foreign cookies on logout (and in general the cookies aren't actually removed, but set to empty values) Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Authentication Assignee: koha-bugs@lists.koha-community.org Reporter: schodkowy.omegi-0r@icloud.com QA Contact: testopia@bugs.koha-community.org CC: dpavlin@rot13.org So Koha tries to remove all cookies on logout apparently, even if they don't belong to her. It does so improperly though, only resulting in a new cookie being created. So we have Koha's CGISESSID on opac.library.com and then WEB360SESSID on .library.com (ie. library's main site, that set the cookie on subdomains, because the main site also has some sub-domains). With the above, removing such a cookie is NOT EXPECTED, because logging out from Koha will interfere with independent unrelated sites on other subdomains. Koha ideally SHOULD NOT try to remove cookies from a different domain. The problem is, the cookies are innocently sent like this: Cookie: WEB360SESSID=ab2e1sngdb7odgfh68h1vp4j8l; CGISESSID=f4b8837f0bb7040ac96c2c9361cdcc02 So how can we even tell if a cookie is to be removed or not??? Anyway what Koha tries to do is: set-cookie: WEB360SESSID=; path=/; secure set-cookie: CGISESSID=7b5138e06ed10fd6c11e4c8d5de73c73; path=/; secure; HttpOnly; SameSite=Lax Well, this simply ends up creating a brand new new empty WEB360SESSID cookie on opac.library.com, while the cookie at .library.com remains intact, which is obviously a broken behavior. The actual removal attempt happens here it seems, just as some initial pointer: https://github.com/Koha-Community/Koha/blob/a524d94abb9b3634ed92186e94d68fdb... But we should abuse the fact that Set-Cookie defaults to the current subdomain, and use Max-Age=0 to immediately delete the cookie (this is the other side of the coin, current behavior won't remove the cookie, it will just set it to empty value with indefinite expiration!). This way we'd both improve the behavior by actually cleaning up the cookies, and still not making Koha end up overreaching what it might remove, given there's no way to tell from Cookie header what subdomain the cookie was set for. Of course if someone wanted to push another avenue of removing cookies of higher-level domain, they'd need to use JavaScript to do that probably. But they shouldn't, since Koha shouldn't touch other sites, period. Also the comment in linked code is: "-expires explicitly omitted to create shortlived 'session' cookie"; and that's wrong because a session could last for months or years. It's not said that the browser will clear it on its restart either. Another cherry on top: path also isn't set on clearout. This will also miss clearing out some cookies, even ones on the same subdomain. See: https://stackoverflow.com/questions/20320549/how-can-you-delete-a-cookie-in-... RFC 6265:
Finally, to remove a cookie, the server returns a Set-Cookie header with an expiration date in the past. The server will be successful in removing the cookie only if the Path and the Domain attribute in the Set-Cookie header match the values used when the cookie was created.
But now that I think about it, you don't get path in Cookie header either. Uh, so I guess JavaScript cookie cleaning it is then? Okay some short summary TLDR: Koha tries to "remove" a cookie by setting it to an empty value, but it fails in that: - no Max-Age=0 is set, meaning a cookie with empty value is created instead, indefinitely (possibly a new redundant one, as in next point) - no Path or Domain are passed, meaning that the cookies with these set to non-default values will not be cleared out (and a new empty cookie will be created instead, without touching the cookies that we want to remove) - different Domain is expected to NOT be cleared out, as that's another site than Koha and we cannot interfere with that - different Path is within Koha subdomain, so not clearing it is problematic in regards to something like Bug 29956 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Michał <schodkowy.omegi-0r@icloud.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29957, | |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29956 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au, | |jonathan.druart@gmail.com, | |m.de.rooy@rijksmuseum.nl --- Comment #1 from David Cook <dcook@prosentient.com.au> --- That's interesting, Michał! I hadn't bumped into this issue, but I just tried it out on a live site with Google Analytics, and I can see on Koha logout that Koha is taking the GA cookie names and setting new cookies with those GA names for "koha.domain.com.au". Although they're session cookies rather than persistent cookies (as you describe - if I understand what you've said correctly), so they'll be cleared out on a browser restart. But yeah... definitely a bug. -- CCing in Jonathan and Marcel as I think they worked on the original code.
From my perspective, I'd say we should only try to manipulate cookies set by Koha, but that would mean keeping an authoritative list somewhere. Koha sets more cookies than just CGISESSID although I don't think they're well documented at the moment...
-- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #2 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Taking a look here -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #2)
Taking a look here
<3 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Michał from comment #0)
So we have Koha's CGISESSID on opac.library.com and then WEB360SESSID on .library.com (ie. library's main site, that set the cookie on subdomains, because the main site also has some sub-domains).
Some preliminary remarks after reading: The construction here makes that you share WEB360SESSID with Koha. You may not be able to change that (or do not want a "long" list of (sub)domain names in that cookie). You could add the cookie name to koha-conf.xml to tell Koha to leave it alone. (Look for do_not_remove_cookie in koha-conf.) Coming back to other points soon. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #4)
names in that cookie). You could add the cookie name to koha-conf.xml to tell Koha to leave it alone. (Look for do_not_remove_cookie in koha-conf.)
That's interesting. One of those configs I think that I've seen but never paid any attention to... Looking at bug 31250 I can see why we went with "do_not_remove_cookie" to create a "keep cookie list", although I suspect the idea was based on the idea that all existing cookies would be set/managed by Koha, which isn't the real world scenario, unfortunately. The "do_not_remove_cookie" list could work well in conjunction with a hard-coded list of Koha cookies. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #6 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 182758 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182758&action=edit Bug 39206: Add whitelist to Koha::CookieManager This patch adds a bit more control to what CookieManager does by adding a hardcoded whitelist of cookie names that are cleared at logout. Allowing at the same time to add entries to that list by using koha-conf <remove_cookie> lines or removing entries from the hardcoded list by using <do_not_remove_cookie> lines. The patch fixes the expiration of cookies that should be removed by passing max-age 0. Also it adds a theoretical path correction for always_show_holds but since we do not clear that cookie, it is currently unused. This seems to be the only Koha cookie where we use a longer path. Test plan: Run t/CookieManager.t Go to OPAC, login, select a few OPAC search results and send them to cart. This would create cookie bib_list. (Check dev tools.) Logout from OPAC and check cookie in your browser dev tools. What you see, depends on the browser. But the cookie should be either gone or empty and expired (FF: Session). Now add a <do_not_remove_cookie> line for bib_list in koha-conf. Restart all. Logout (OPAC or staff). Check again in dev tools that bib_list is not empty, not expired. Check out an item. And click on 'Always show checkouts...' on the patron checkout form. This should create the cookie with value DO. Logout from intranet. Check that cookie was not affected. Now add a <remove_cookie> line for the following cookie: issues-table-load-immediately-circulation. Restart all. Login and logout from staff again. Check that cookie is empty and expired, or just gone. Bonus for devs: Create some custom cookie, and test keeping or removing it similar as above. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 182759 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182759&action=edit Bug 39206: Modify koha-conf templates Test plan: Just read the patch. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |m.de.rooy@rijksmuseum.nl |ity.org | Version|24.05 |Main -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #8 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Michał from comment #0)
Okay some short summary TLDR: Koha tries to "remove" a cookie by setting it to an empty value, but it fails in that: - no Max-Age=0 is set, meaning a cookie with empty value is created instead, indefinitely (possibly a new redundant one, as in next point)
Good point. Fixed in this patch set.
- no Path or Domain are passed, meaning that the cookies with these set to non-default values will not be cleared out (and a new empty cookie will be created instead, without touching the cookies that we want to remove) - different Domain is expected to NOT be cleared out, as that's another site than Koha and we cannot interfere with that - different Path is within Koha subdomain, so not clearing it is problematic in regards to something like Bug 29956
The patch now uses a whitelist that can be refined with entries from koha-conf. So should no longer touch other ones. Path defaults to /. No domain means current host. There seems to be only one HttpOnly cookie with a longer path in Koha. If there is a cookie with another path than expected, this patch cannot remove it since the Cookie header line only contains names and values. So we just dont know. But that seems to be a more theoretical issue. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182758|0 |1 is obsolete| | --- Comment #9 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 182760 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182760&action=edit Bug 39206: Add whitelist to Koha::CookieManager This patch adds a bit more control to what CookieManager does by adding a hardcoded whitelist of cookie names that are cleared at logout. Allowing at the same time to add entries to that list by using koha-conf <remove_cookie> lines or removing entries from the hardcoded list by using <do_not_remove_cookie> lines. The patch fixes the expiration of cookies that should be removed by passing max-age 0. Also it adds a theoretical path correction for always_show_holds but since we do not clear that cookie, it is currently unused. This seems to be the only Koha cookie where we use a longer path. Test plan: Run t/CookieManager.t Go to OPAC, login, select a few OPAC search results and send them to cart. This would create cookie bib_list. (Check dev tools.) Logout from OPAC and check cookie in your browser dev tools. What you see, depends on the browser. But the cookie should be either gone or empty and expired (FF: Session). Now add a <do_not_remove_cookie> line for bib_list in koha-conf. Restart all. Repeat search, add to cart. Logout. Check again in dev tools that bib_list is not empty, not expired. Check out an item. And click on 'Always show checkouts...' on the patron checkout form. This should create the cookie with value DO. Logout from intranet. Check that cookie was not affected. Now add a <remove_cookie> line for the following cookie: issues-table-load-immediately-circulation. Restart all. Login and logout from staff again. Check that cookie is empty and expired, or just gone. Bonus for devs: Create some custom cookie, and test keeping or removing it similar as above. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182759|0 |1 is obsolete| | --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 182761 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182761&action=edit Bug 39206: Modify koha-conf templates Test plan: Just read the patch. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This patch adds more release notes| |control to | |Koha::CookieManager by | |allowing to refine its list | |of managed cookies with | |keep or remove entries in | |koha-conf.xml. | | | |IMPORTANT | |NOTE: The former (probably | |widely unused) feature of | |putting a regex in the | |do_not_remove_cookie lines | |is replaced by interpreting | |its value as a prefix. (So | |you should e.g. replace | |catalogue_editor_\d+ by | |just catalogue_editor_ -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182760|0 |1 is obsolete| | --- Comment #11 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 183234 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183234&action=edit Bug 39206: Add whitelist to Koha::CookieManager This patch adds a bit more control to what CookieManager does by adding a hardcoded whitelist of cookie names that are cleared at logout. Allowing at the same time to add entries to that list by using koha-conf <remove_cookie> lines or removing entries from the hardcoded list by using <do_not_remove_cookie> lines. The patch fixes the expiration of cookies that should be removed by passing max-age 0. Also it adds a theoretical path correction for always_show_holds but since we do not clear that cookie, it is currently unused. This seems to be the only Koha cookie where we use a longer path. Test plan: Run t/CookieManager.t Go to OPAC, login, select a few OPAC search results and send them to cart. This would create cookie bib_list. (Check dev tools.) Logout from OPAC and check cookie in your browser dev tools. What you see, depends on the browser. But the cookie should be either gone or empty and expired (FF: Session). Now add a <do_not_remove_cookie> line for bib_list in koha-conf. Restart all. Repeat search, add to cart. Logout. Check again in dev tools that bib_list is not empty, not expired. Check out an item. And click on 'Always show checkouts...' on the patron checkout form. This should create the cookie with value DO. Logout from intranet. Check that cookie was not affected. Now add a <remove_cookie> line for the following cookie: issues-table-load-immediately-circulation. Restart all. Login and logout from staff again. Check that cookie is empty and expired, or just gone. Bonus for devs: Create some custom cookie, and test keeping or removing it similar as above. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #182761|0 |1 is obsolete| | --- Comment #12 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 183235 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183235&action=edit Bug 39206: Modify koha-conf templates Test plan: Just read the patch. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #13 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 183497 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183497&action=edit Bug 39206: Add an allowlist to Koha::CookieManager This patch adds a bit more control to what CookieManager does by adding a hardcoded allowlist of cookie names that are cleared at logout. Allowing at the same time to add entries to that list by using koha-conf <remove_cookie> lines or removing entries from the hardcoded list by using <do_not_remove_cookie> lines. The patch fixes the expiration of cookies that should be removed by passing max-age 0. Also it adds a theoretical path correction for always_show_holds but since we do not clear that cookie, it is currently unused. This seems to be the only Koha cookie where we use a longer path. Test plan: Run t/CookieManager.t Go to OPAC, login, select a few OPAC search results and send them to cart. This would create cookie bib_list. (Check dev tools.) Logout from OPAC and check cookie in your browser dev tools. What you see, depends on the browser. But the cookie should be either gone or empty and expired (FF: Session). Now add a <do_not_remove_cookie> line for bib_list in koha-conf. Restart all. Repeat search, add to cart. Logout. Check again in dev tools that bib_list is not empty, not expired. Check out an item. And click on 'Always show checkouts...' on the patron checkout form. This should create the cookie with value DO. Logout from intranet. Check that cookie was not affected. Now add a <remove_cookie> line for the following cookie: issues-table-load-immediately-circulation. Restart all. Login and logout from staff again. Check that cookie is empty and expired, or just gone. Bonus for devs: Create some custom cookie, and test keeping or removing it similar as above. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183235|0 |1 is obsolete| | --- Comment #14 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 183498 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183498&action=edit Bug 39206: Modify koha-conf templates Test plan: Just read the patch. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |martin.renvoize@openfifth.c |y.org |o.uk CC| |martin.renvoize@openfifth.c | |o.uk Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #183234|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA --- Comment #15 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Taking Paul's SO line as a signoff.. this all appears to work as expected to me and I can't see any security risks this exposes.. No regressions found and the QA scripts are happy. Passing QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #16 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Note, I updated the commit message of the first commit.. 'allowlist' is the modern term, we tend to about 'white' or 'black' lists now ;) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |25.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #17 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Nice work everyone! Pushed to main for 25.11 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|25.11.00 |25.11.00,25.05.02 released in| | Status|Pushed to main |Pushed to stable -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 --- Comment #18 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Nice work everyone! Pushed to 25.05.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Needs documenting CC| |fridolin.somers@biblibre.co | |m --- Comment #19 from Fridolin Somers <fridolin.somers@biblibre.com> --- I prefer not impact 24.11.x for stabilily -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39206 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Needs documenting |RESOLVED --- Comment #20 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- I don't think there is anything here that changes something in the Koha manual. Feel free to reopen with more details if a change to the manual is necessary. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org