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

[Bug 12450] Easily close a branch
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12450 Sarah Cornell <sbcornell(a)cityofportsmouth.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbcornell@cityofportsmouth. | |com --- Comment #16 from Sarah Cornell <sbcornell(a)cityofportsmouth.com> --- Our Koha instance has one public library and five school libraries. We are also interested in a built-in, somewhat comprehensive method for closing the school libraries for 2.5 months every summer. We'd like to see a couple of things: * make items appear as "not available" in the catalog when the branch is closed * make the holds queue not take the closed branch's items into account I'm willing to make a handful of changes every year at the end/beginning of a school year, but I can't afford the time to completely turn on and off circ rules one by one, for example. Thanks, Christopher for getting this rolling 11 years ago. ;) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39875] New: ILL - History check fails if unauthenticated request
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39875 Bug ID: 39875 Summary: ILL - History check fails if unauthenticated request Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Depends on: 38441 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38441 [Bug 38441] Allow for an ILL history check workflow stage -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 40534] New: Fields in item form different sizes
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40534 Bug ID: 40534 Summary: Fields in item form different sizes Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I noticed the fields in the item creation/modification form are no longer all the same size. The drop-downs are much longer than the text inputs. A bisect pointed to bug 39533, but that bug is about the export tool, so I'm not sure if it's the correct one, or it simply had a much larger/unintended scope. To recreate : 1. In the staff interface, go to a biblio record (e.g. http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=285) 2. Click New > New item --> Notice the fields in the form are different sizes from each other, the selects being much longer than the text inputs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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)
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

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(a)lists.koha-community.org Reporter: schodkowy.omegi-0r(a)icloud.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)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/a524d94abb9b3634ed92186e94d68fd… 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.

1 29

[Bug 35087] New: Discount rate does not accept comma as decimal separator
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35087 Bug ID: 35087 Summary: Discount rate does not accept comma as decimal separator Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello all, When a comma is used to define the discount rate of a vendor, the data is not recorded (as NULL), it is however recorded if the separator is a point. In the same way that the BZ rectifying the problems linked to the payment of fines (bug 33028) obliges the input with a point I will propose a corrective in this same direction. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 40533] New: Clicking "Invoices" in vendor file doesn't show the vendor's invoices
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40533 Bug ID: 40533 Summary: Clicking "Invoices" in vendor file doesn't show the vendor's invoices Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When I'm in a vendor file (http://localhost:8081/cgi-bin/koha/acquisition/vendors/1) and I click 'Invoices' in the left-hand side menu, I expect to see that vendor's invoices. Instead, I'm in the general invoices page and I need to click 'Search' at the bottom of the page to get that vendor's invoices. This might be a side-effect of bug 38010, I'm not sure, but I tested on a local installation of 24.05.05 and when I click on Invoices from a vendor file, I immediately see the vendor's invoices, without having to scroll to the bottom and click 'Search'. To recreate : 1. Create a basket, add an order, and close the basket 1.1. Go to Acquisitions 1.2. Search for "My Vendor" 1.3. Click "1 basket(s)" 1.4. Click "Add to basket" 1.5. Click "From a new (empty) record" 1.6. Enter a title 1.7. Choose an item type in "y - Koha item type" 1.8. Click "Add item" 1.9. Choose a fund 1.10. Enter a vendor price 1.11. Click "Save" 1.12. Click "Close basket" 1.13. Click "Yes, close" 2. Create an invoice and receive the order 2.1. Click "Receive shipments" 2.2. Enter an invoice number 2.3. Click "Next" 2.4. Click "Receive" next to the order 2.5. Check the box under "Receive?" 2.6. Click "Confirm" 2.7. Click "Finish receiving" 3. Go to the vendor file and try to view the list of invoices 3.1. Go to Acquisitions home page 3.2. Search for "My Vendor" 3.3. Click "My Vendor (#1)" 3.4. Click "Invoices" in the left-hand side menu --> The vendor's invoices are not displayed 3.5. In the filters on the left side, notice the vendor "My vendor" is already selected (I'm not sure if this is because we only have one vendor, or because Koha know this is the vendor it's supposed to be searching for) 3.6. Scroll to the bottom and click "Search" --> The invoice appears -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 34159] New: Remove plan by AR_CANCELLATION choice in aqplan
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34159 Bug ID: 34159 Summary: Remove plan by AR_CANCELLATION choice in aqplan Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I'm not sure if this is my data, but I see it on my local master as well as on the bywater and ptfs-e sandboxes... When I go to Plan by X in the Funds administration, there is an option to Plan by AR_CANCELLATION, which is weird and uncecessary (and also doesn't work). To recreate: 1. Add a budget 1.1. Go to Administration > Budgets 1.2. Click 'New budget' 1.3. Fill in the form (make sure there are a couple of months between the start and end dates), e.g. - Start date: 01/01/2023 - End date: 12/31/2023 - Description: 2023 - Total amount: 10000 - Make budget active: check - Lock budget: leave unchecked 1.4. Click 'Save' 2. Add at least one fund to the budget, make sure not to choose any statistics 1/2 2.1. Click 'Actions' next to the budget and choose 'Add fund' 2.2. Fill out the form, e.g. - Fund code: PRINT - Fund name: Print material - Amount: 6000 2.3. Click 'Submit' 3. View the planning page, e.g. Plan by months 3.1. Click 'Planning' at the top of the page and choose 'Plan by months' 3.2. In the Filter box on the left, open the 'Select planning type' drop-down menu --> There is one choice called 'Plan by AR_CANCELLATION' I checked all my funds and all the funds in the sandboxes and none have AR_CANCELLATION as a statistic 1 or 2. If you select this option and click 'Submit', it says there is nothing to show. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 38899] New: Allow the Vue toolbar to be sticky
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38899 Bug ID: 38899 Summary: Allow the Vue toolbar to be sticky Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com We have sticky toolbars throughout Koha but this is not yet supported in Vue apps. The Toolbar component should have a sticky mode enabled -- You are receiving this mail because: You are watching all bug changes.

1 77

[Bug 40067] New: "Receive shipments" opens in a new tab/window
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40067 Bug ID: 40067 Summary: "Receive shipments" opens in a new tab/window Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 38010 On the vendor view: http://localhost:8081/cgi-bin/koha/acquisition/vendors/1 click "Receive shipments" in the toolbar http://localhost:8081//cgi-bin/koha/acqui/parcels.pl?booksellerid=1 is opened in a separate tab/window Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38010 [Bug 38010] Migrate vendors to Vue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 38298] New: Edifact breadcrumbs need to be permissions based
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38298 Bug ID: 38298 Summary: Edifact breadcrumbs need to be permissions based Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The breadcrumbs in ed_accounts.pl point to Administration but if the user doesn't have permissions for this then they can't access the page. It should be permissions based and point to acquisitions if they don't have permission to access administrations -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15