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

[Bug 37614] New: Printing patron cards from patron lists broken by CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37614 Bug ID: 37614 Summary: Printing patron cards from patron lists broken by CSRF protection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, oleonard(a)myacpl.org Blocks: 36192 Steps to reproduce: 1. Tools - Patrons lists, if you don't already have one then New list, name and save, Search for patrons, add at least one patron, then return to Patron lists. 2. In the Actions menu for your patron list, select Print patron cards 3. In that perfectly normal looking popup, click Export. You now have a popup with an Loading throbber, which will hang forever, and in your console you have a 403 error from trying to GET patroncards/print.pl. If you go back and inspect the page where you clicked Export, you'll find that it is a button type='submit' in a form with method='post' which makes the GET seem a bit odd. To see that it sometimes posts, 1. Tools - Patron card creator - New card batch - Add at least one patron 2. Export card batch 3. You get a popup with a lovely Windows 95 aesthetic courtesy of greybox.inc, but it is that same form method='post' with the same type='submit' Export button. Click Export and you will POST to patroncards/print.pl and things will work just fine. Not at all clear to me how opening the popup one way turns the POST to a GET, but it does. There's a FIXME in patroncards/print.pl saying that the op=cud-export looks sus, which it does. You could try to make the case that it's sensible to POST because in the case where you have selected some but not all of the patrons in a label batch, the number of label_id params in the URL could be so high that it exceeds Apache's max URL length, but then the result of the POST is a link to create the PDF that is the actual "print" export, and that link is a GET which contains all of them with an over-escaped &label_id= param for each one. So a pragmatic fix would be to just change from a POST to a GET, change cud-export to export, and not worry about why called one way it POSTs and called another way it GETs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 7012] Limit to available does not exclude in-transit items
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7012 --- Comment #20 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #9) > Elasticsearch and Zebra both index MARC. So bibliographic records and items. Technically, I don't think that's 100% true. We've made the search engines MARC-focused with Koha, but they don't have to be. We process MARC records and turn them into JSON document for Elasticsearch. We pass MARCXML records to zebraidx for Zebra, but technically we should be able to wrap the MARCXML with our own "Koha XML" and inject whatever we want. I don't think that this was possible with GRS-1 indexing but it should be with the DOM indexing. But the tricky part isn't the indexing. It's managing the state in the database across a huge range of Perl functions. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7012] Limit to available does not exclude in-transit items
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7012 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #19 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Martin Renvoize (ashimema) from comment #14) > This is the sort of thing I'd love to see the foundation sponsor once it's > setup.. we all agree it's a bug and should be fixed, we just can't easily > prioritise it individually when we have bills of our own to pay. I think one of the problems here is also agreeing on a design. Joubu linked me to bug 7012 from bug 38181 as I point out the performance problems with calculating item status using the ORM item by item at search time. Bug 37334 will suffer from the same problem as bug 38181. Off the top of my head, we need to be storing the status in the database and indexing that. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard(a)myacpl.org |koha-bugs(a)lists.koha-commun | |ity.org Component|Templates |Notices --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jessie Zairo from comment #6) > Adding +1 to this. I had a nice chat with Jessie and some others about this at Kohacon. While it's not on my list of priorities, this would be a fun/interesting one to do. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 36801] New: Allow un-resolving of a catalog concern
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36801 Bug ID: 36801 Summary: Allow un-resolving of a catalog concern 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We didn't allow for re-opening a resolved catalog concern before, but with the introduction of the update status's I think we managed to change the logic a bit and the 'Update' button now displays. This effectively allows for re-opening a resolved ticket; However, the actual ticket state isn't properly updated and should be so the new state is properly reflected in the display table and filtering options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 37055] New: WaitingNotifyAtCheckout should only trigger on patrons with waiting holds
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37055 Bug ID: 37055 Summary: WaitingNotifyAtCheckout should only trigger on patrons with waiting holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When one patron has a waiting hold, Koha pops up a modal when checking out to any patrons. To recreate: - enable WaitingNotifyAtCheckout - have or create a waiting hold for a patron - check out an item to a different patron who does not have a waiting hold - Koha says "This patron has waiting holds that are available for checkout" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 36276] New: Cannot edit Identity Provider after creation
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36276 Bug ID: 36276 Summary: Cannot edit Identity Provider after creation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: olivier.hubert(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Once an identity provider is created, it is no longer possible to easily edit it, as the form for editing the identity provider contains no value. Moreover, the provider's name is replace with " (quotation mark). Steps to reproduce: 1. Launch KTD or Koha instance using up-to-date master branch. 2. In the Administration menu, go to the Identity Providers page. 3. Click on the button to create a new identity provider. 4. Fill in the required fields, using test data. 5. Save the identity provider. 6. Click the "Edit" button for the newly created identity provider. 7. Notice that the form's fields are empty and the provider's name has been changed to ". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 37612] New: Batch modifying patrons from patron lists broken by CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37612 Bug ID: 37612 Summary: Batch modifying patrons from patron lists broken by CSRF protection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 36192 Patron lists have an Actions menuitem to Batch edit patrons, which sends a GET to tools/modborrowers.pl?patron_list_id=1&op=show. But because the other two ways to modborrowers are to upload a file of borrowernumbers or to stick a possibly-huge number of borrowernumbers into a textarea, both of which require a POST, the op is now cud-show, not because it does anything CUD, but because it has to accept POSTs. It just needs the same solution as https://git.koha-community.org/Koha-community/Koha/src/commit/99c2064126978… to accept both cud-show and show. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 38220] New: Show number of baskets on the Vendor details page
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38220 Bug ID: 38220 Summary: Show number of baskets on the Vendor details page Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: angela.berrett(a)familysearch.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 173075 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=173075&action=e… Add Basket/Subscription count to Vendor details page. The Vendor search results show the number of baskets and subscriptions. When opening a Vendor's details page it requires going in to the Baskets tab to see the count of baskets/subscriptions. Can that same information from the results page be added to the top of the Vendor details page? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 38075] New: SCO "Log out and try again with a different user" link doesn't work
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38075 Bug ID: 38075 Summary: SCO "Log out and try again with a different user" link doesn't work Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I'm testing the Web-based self checkout module. When you enter the login/password of a patron without the self check permission, there is a message Access denied Sorry, the system doesn't think you have permission to access this page. With a link Log out and try again with a different user. When I click this link, I expect to be redirected to the login page to try again. However, the link doesn't do anything. -- You are receiving this mail because: You are watching all bug changes.

1 1