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

[Bug 38214] New: Audit use of TT url filter for uses that should be uri instead
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38214 Bug ID: 38214 Summary: Audit use of TT url filter for uses that should be uri instead Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Shame the two things look so much alike in so many fonts, when you have old eyes. The url filter is for filtering a full URL, when you don't want to escape : or // since starting a URL with http%3A%2F%2F won't work well. The uri filter is for filtering a URL parameter, where you want '/search?query=why%3F' rather than '/search?query=why?' which breaks your URL by having a second '?'. Using url when you should use uri means you are leaving &, @, /, ;, :, =, +, ? and $ unescaped when you shouldn't. In many cases, the wrong use of url is on things like biblionumber, where that doesn't result in any interesting behavior, but in other cases... you can create an authorized value category named This&That=Stuff, and when you try to add a value to it, you will add a value to the category This, and pass the parameter That with the value Stuff to the script. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 38719] New: ILL : display in the request the name of the partner library providing the document
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38719 Bug ID: 38719 Summary: ILL : display in the request the name of the partner library providing the document 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com When you request a document from a partner, the request status become "Requested from partners" and the partner email is displayed. The name of the partner should be displayed too -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21482] New: Create a "landing page" for ILL
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21482 Bug ID: 21482 Summary: Create a "landing page" for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Currently, when you go to the ILL module, the first iew is of all ILL requests. This can be a lot of data, and take several seconds to load, and I doubt a lot of people will want the full list. So maybe we could have some sort of intermediate page with links to selections of request, based on their status, type etc. At it's simplest this could just be a page that displays the contents of a syspref, and that syspref could then be filled with HTML and links to filtered views of ILL requests. If the syspref is empty, the intermediate page could redirect to the full view, as it is today. A more advanced version would have a GUI to configure the links, order them, give them names etc. Thougts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 36779] New: Automatic renewal column doesn't always populate correctly when editing
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36779 Bug ID: 36779 Summary: Automatic renewal column doesn't always populate correctly when editing Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If I'm editing a rule with Yes in the 'Automatic renewal' column and then select to edit a different rule that has No in the 'Automatic renewal' column without saving the first rule, Yes 'sticks'/remains populate for the second rule. To recreate: 1. Select Edit on a rule with Yes in 'Automatic renewal'. Note that Yes populates (as it should) in the editing line. 2. Without saving any changes to the rule selected above, click Edit on a rule with No in the 'Automatic renewal' column. Note that Yes still shows in the 'Automatic renewal' column, even though other values have populated from the second rule you selected to edit. If a library doesn't notice this, they could accidentally set rules for automatic renewal when making other unrelated edits. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33361] New: Renewals prevented on items where there is an item level hold on another item on the record
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33361 Bug ID: 33361 Summary: Renewals prevented on items where there is an item level hold on another item on the record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: Ability to override holds is needed Find/create a record with 2 items Checkout item A to a patron Place an item level hold on B for another patron Item A cannot be renewed Override renewal to renew the item It gives you a new due date but doesn't actually update the item. This also happens with autorenewals being blocked when there is an item level hold on another item on the record. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 28781] New: Elasticsearch facets may be inaccurate
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28781 Bug ID: 28781 Summary: Elasticsearch facets may be inaccurate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com To recreate: 1 - Set system preferences: SearchEngine: Elasticsearch FacetMaxCount: 20 displayFacetCount: Show 2 - Using koha testing docker default data search for '*' 3 - Note the author facets like Beckett, Samuel (5) Aristophanes (3) De Niese, Danielle (3) Euripides (3) Aristotle (2) 4 - Set FacetMaxCount:400 5 - Repeat search 6 - Note facets like: Beckett, Samuel (5) Stevens, W. Richard (5) Plato (4) Aristophanes (3) De Niese, Danielle (3) 7 - Some top terms are missing when FacetMaxCount is passed to ES as 'size' >From the docs: The size parameter can be set to define how many term buckets should be returned out of the overall terms list. By default, the node coordinating the search process will request each shard to provide its own top size term buckets and once all shards respond, it will reduce the results to the final list that will then be returned to the client. This means that if the number of unique terms is greater than size, the returned list is slightly off and not accurate (it could be that the term counts are slightly off and it could even be that a term that should have been in the top size buckets was not returned). https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-aggregat… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 35607] New: Multi-receiving only receives orders visible on the screen
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35607 Bug ID: 35607 Summary: Multi-receiving only receives orders visible on the screen Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 8179 When receiving multiple orders, one first selects the orders to receive on /cgi-bin/koha/acqui/parcel.pl?invoiceid= and is then taken to a list of those selected titles on /cgi-bin/koha/acqui/orderreceive.pl?multiple_orders=. The multiple orders page defaults to showing 20 orders per page. When one hits "Confirm" to complete receipt of orders, only the orders visible on the page will be received. To recreate: - have 21 orders ready to receive from a vendor - create an invoice for your vendor. select all 21 orders on /cgi-bin/koha/acqui/parcel.pl, click Receive Selected - on /cgi-bin/koha/acqui/orderreceive.pl, see that koha tells you it is showing 1-20 of 21 orders - Use the Edit Order modal to set the quantity received for all 21 orders - Click Save Changes in the Edit Order modal and then click Confirm - See that Koha has only received the first 20 orders, even though you entered a Quantity Received value for order 21 When updating order information via the Edit Order modal on this page, the Next and Previous Order buttons will cycle the user through Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 [Bug 8179] Receiving multiple order lines at once -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 22320] New: Make ILL comments visible to all staff
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22320 Bug ID: 22320 Summary: Make ILL comments visible to all staff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- The ILL module has several kinds of comments that are only visible to staff who have access to the ILL module. This is a problem because any librarian can get the question "how is my ILL coming along" from a patron at the front desk. We should make some or all of the comments, and probably also the status, of ILL requests visible to all staff in the normal detail view, so they can answer questions about ILL loans that have not arrived at the library yet. It might be a good idea to have sysprefs to let libraries choose which comments should be visible to "other" staff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 27049] New: It would be helpful to have a bulk waive of debts tool
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27049 Bug ID: 27049 Summary: It would be helpful to have a bulk waive of debts tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz With extended periods of libraries being closed and the recent complexities introduced into the accounts system for properly tracking accountline writeoffs, it would be helpful to have a command line too allowing administrators to writeoff accounts in bulk using the proper routines within Koha to properly record the action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 38244] New: Add logging to writeoff_debts.pl cronjob
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38244 Bug ID: 38244 Summary: Add logging to writeoff_debts.pl cronjob Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: Slodico(a)knoxlib.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Add running this cronjob to Koha logs. I don't believe the details of each fine that has been written off needs to be logged, but the fact that the script ran, either successfully or not, would be useful information to have. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1