June 2023 - Koha-bugs - lists.koha-community.org

[Bug 28104] New: last line of sitemapindex.xml lacks EOL
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28104 Bug ID: 28104 Summary: last line of sitemapindex.xml lacks EOL Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: bargioni(a)pusc.it QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, robin(a)catalyst.net.nz CC: jonathan.druart(a)bugs.koha-community.org $ /usr/sbin/koha-sitemap --generate instance generates file /var/lib/koha/instance/sitemap/sitemapindex.xml without the EOL of the last line. XML parsers can complain, e.g.: $ xmllint --format /var/lib/koha/instance/sitemap/sitemapindex.xml /var/lib/koha/instance/sitemap/sitemapindex.xml:22: parser error : expected '>' </sitemapindex> ^ /var/lib/koha/instance/sitemap/sitemapindex.xml:22: parser error : Premature end of data in tag sitemapindex line 3 </sitemapindex> ^ --- Comment #1 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- I don't recreate the problem. Can you provide more detail please? $ perl debian/scripts/koha-sitemap --enable kohadev Sitemap enabled for kohadev $ perl debian/scripts/koha-sitemap --generate kohadev Sitemap directory for kohadev doesn't exist. Creating. $ xmllint --format /var/lib/koha/kohadev/sitemap/sitemapindex.xml <?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>http://kohadev.myDNSname.org:8080/sitemap0001.xml</loc> <lastmod>2021-04-09</lastmod> </sitemap> </sitemapindex> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28098] New: Allow for editing public parameter for Upload tool
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28098 Bug ID: 28098 Summary: Allow for editing public parameter for Upload tool Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: eugenegf(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org Currently (19.11), the Upload (Any File) tool does not let you change the parameter for Public. There should be a way for editing uploaded files into public and vice versa. Currently, if you want to do this, you have to hack the database and change the 'public' column to 1 if it's public and remove the value '1' if you don't want to make it public. --- Comment #1 from Séverine Queune <severine.queune(a)bulac.fr> --- *** Bug 28099 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 28065] New: "Edit report" option when selecting parameters
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28065 Bug ID: 28065 Summary: "Edit report" option when selecting parameters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org When a report allows the user to fill parameters (with <<Item type|itemtypes>> for exemple), it could be useful to have an option to edit the report on the "phase=Run this report" page where you have to select the different parameters. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28062] New: Allow batch removal of waiting holds
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28062 Bug ID: 28062 Summary: Allow batch removal of waiting holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the "Holds Awaiting Pickup" button in "Circulation", it would be nice if there could be a batch delete function - if a user has to cancel a lot of holds they can only be done one at a time and the screen has to rebuild between each deletion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28059] New: Move OPAC news block to new protected area
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28059 Bug ID: 28059 Summary: Move OPAC news block to new protected area Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org The OPAC news block items should be separated out to a new permission protected area. It is too easy to forever delete OPAC customizations by library staff who otherwise should be able to use the news tool. Our consortium recently experienced this when someone accidentally deleted all the OPAC news blocks. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 28051] New: On upgrade to 19.11, per-item Writeoff got confused with Lost
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28051 Bug ID: 28051 Summary: On upgrade to 19.11, per-item Writeoff got confused with Lost Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: pongtawat(a)punsarn.asia QA Contact: testopia(a)bugs.koha-community.org During upgrade to 19.11, database upgrade script introduced by Bug #22563 (convert "lost" handling) also handle case of normal per-item writeoff like those writeoff generated from lost. So, all patron with normal per-item writeoff will now see additional account line of 'LOST' type. This is due to the following code in updatedatabase.pl: # Find and correct pathalogical cases of L having been converted to W $sth = $dbh->prepare( "SELECT accountlines_id, issue_id, borrowernumber, itemnumber, amount, manager_id FROM accountlines WHERE accounttype = 'W' AND itemnumber IS NOT NULL" ); ... Step to reproduce: 1. Start with Koha 18.05. 2. Create overdue fine on item X for patron A, amount=100. 3. Per-item write-off amount=50 on item X for patron A. This will create 'W' line in accountlines with amount=50 and item=X 4. Upgrade to Koha 19.11 or later (in our case 20.05) 5. Patron A now has an additional 'LOST' with amount=50 and item=X in their accountlines. This additional 'LOST' line is incorrect in this case. Also, I notice that this per-item writeoff is in debit side (red). I don't know if this is correct or not, but shouldn't writeoff be on credit side? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28049] New: Elements on most staff interface pages move tiny bit after page is fully reloaded
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28049 Bug ID: 28049 Summary: Elements on most staff interface pages move tiny bit after page is fully reloaded Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you load most Koha staff interface pages, e.g. front page, you notice that the HTML elements on the page move slightly after the page is fully loaded. This seems to happen because of the Search bar changing its size tiny bit probably due to some JS stuff. You can also easily reproduce the problem by clicking on the Koha search text box and then clicking outside of it, you should notice the slight movement of the HTML elements. This is annoying and causes misclicks! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28029] New: Add ability to use OFFSET in SQL reports
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28029 Bug ID: 28029 Summary: Add ability to use OFFSET in SQL reports Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: joe(a)flo.org QA Contact: testopia(a)bugs.koha-community.org As far as I can tell, you can't use offset [# to offset] or the abbreviated limit [# to offset], [# to limit] shorthand to offset your results in Koha's SQL reports. These features are available in MySQL and Mariadb, so it would be nice if you could use one of them on the front end. Here are two simple examples that don't work: select borrowernumber from borrowers limit 10, 10 select borrowernumber from borrowers limit 10 offset 10 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28025] New: allow option for when to send autorenew denied/onhold notices
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28025 Bug ID: 28025 Summary: allow option for when to send autorenew denied/onhold notices Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 19014 changed when autorenew notices for items with a hold on them was sent. Some libraries have asked for the option to decide when those notices will be sent. For example: Item is checked out on March 1 and has holds on it. Autorenew set for 0, so patrons will get the no-renewal notice the day the item is due. The library would like to send the no autorenew notice perhaps 5 days prior to the due date, independent of actually trying to renew the item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 28024] New: Remove X-Abuse-Report header adding in opac-sendbasket.pl
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '23

01 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28024 Bug ID: 28024 Summary: Remove X-Abuse-Report header adding in opac-sendbasket.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I'm reporting this mainly to hear from other devs. I found opac-sendbasket.pl is the only place Koha sets that header, and a search tells me it is not standard and is used with several (other) names. In my opinion, such custom header should be configurable, or totally handled in the MTA. And if it was something that should be configurable or even mandatory, shouldn't it be set for all emails? At Koha::Email? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4