March 2020 - Koha-bugs - lists.koha-community.org

[Bug 24809] New: OAI PMH can fail on fetching deleted records
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24809 Bug ID: 24809 Summary: OAI PMH can fail on fetching deleted records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When calling GetRecord if we pass a deleted biblionumber that has a deleted item we can end up thinking a record that is deleted is not deleted and so fail on getting the record The problem is here: 48 UNION 49 SELECT timestamp from deleteditems 50 WHERE biblionumber=? If you delete an item from a record, then delete the record, the first query gets a timestamp and then attempts to get the record as if it is not deleted To recreate: 1 - Edit/create a file in the koha home dir '/var/lib/koha/{instance}/OAI.yaml 2 - Set sysprefs: OAI-PMH => Enable OAI-PMH:ConfFile => /var/lib/koha/{instace}/OAI.yaml 3 - View a record with items and confirm the items show: http://localhost:8080/cgi-bin/koha/oai.pl?verb=GetRecord&metadataPrefix=mar… 4 - Delete the items, then delete the record 5 - Reload the URL from step 3 6 - Internal Server Error: Empty String at /kohadevbox/koha/Koha/OAI/Server/Record.pm line 58. at /usr/share/perl/5.24/Carp.pm line 167 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 24114] New: modules must not warn
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24114 Bug ID: 24114 Summary: modules must not warn Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Bug 21336 introduced warn statements in Koha::Patrons. That should be avoided, the warn must be done in the cronjob script. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 24527] New: misc/cronjobs/update_totalissues.pl problem with multiple items
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24527 Bug ID: 24527 Summary: misc/cronjobs/update_totalissues.pl problem with multiple items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz misc/cronjobs/update_totalissues.pl when issuing statistics table has a problem for biblio with multiple items. The first SQL query gets the biblios linked to items with issues in statistics : SELECT biblio.biblionumber, COUNT(statistics.itemnumber) FROM biblio LEFT JOIN items ON (biblio.biblionumber=items.biblionumber) LEFT JOIN statistics ON (items.itemnumber=statistics.itemnumber) WHERE statistics.type = 'issue' $limit GROUP BY biblio.biblionumber The second SQL query is : SELECT biblio.biblionumber, 0 FROM biblio LEFT JOIN items ON (biblio.biblionumber=items.biblionumber) LEFT JOIN statistics ON (items.itemnumber=statistics.itemnumber) WHERE statistics.itemnumber IS NULL GROUP BY biblio.biblionumber The problem is that this second query will set to 0 where ANY item has no entry in statistics table. I think the best fix is to use "WHERE statistics.type = 'issue'" inside que JOIN : LEFT JOIN statistics ON (items.itemnumber=statistics.itemnumber AND statistics.type = 'issue') -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 24711] New: Can't log in to OPAC after logout if OpacPublic disabled
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24711 Bug ID: 24711 Summary: Can't log in to OPAC after logout if OpacPublic disabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org With OpacPublic disabled you are routed to http://localhost:8080/cgi-bin/koha/opac-main.pl?logout.x=1 upon logout. opac-auth.tt adds any inputs it is passed to the login form So you get: <input type="hidden" name="logout.x" value="1"> Login, and immediately get logged out -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 23968] New: OPACMySummaryNote does not work
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23968 Bug ID: 23968 Summary: OPACMySummaryNote does not work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The system preference OPACMySummaryNote is used to display on the logged-in patron summary page at OPAC. It does not display anymore. Looks like it comes from code : [% IF OPACMySummaryNote %][% Koha.Preference('OPACMySummaryNote') | $raw %][% END %] OPACMySummaryNote used to be a provided variable. I propose to fix and add a div with an id to allow tunning of this specific display. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 18100] New: Pay amount, Pay selected and individual pay behaving differently
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18100 Bug ID: 18100 Summary: Pay amount, Pay selected and individual pay behaving differently Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This has been tested with the latest 3.22.x and still needs to be confirmed in newer versions of Koha! In the patron account, there are 3 different options for paying a fine. 2 show the payment as positive in green, one as negative in red. To test: 1) Add manual fee of any type 2) Pay using the pay button next to the fine entry (individual) ==> Verify the payment is displayed in red as positive amount 3) Add manual fee of any type 4) Pay using the "Pay selected" button at the bottom ==> Verify the payment is displayed in green as a negative amount 5) Add manual fee of any type 6) Pay using the "Pay amount" button at the bottom ==> Verify the payment is displayed in green as a negative amount Koha itself seems to deal with it somehow, as the sum at the bottom of the table over all payments and fees is always correct. But the difference is also visible in accountlines and can create quite a mess for reporting. One way to work around it currently is using ABS() before calculating with the amounts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 24765] New: Updated on date in Claims returned starts off as 12/31/1969
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '20

13 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24765 Bug ID: 24765 Summary: Updated on date in Claims returned starts off as 12/31/1969 Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: kyle(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When an item is claimed returned by staff, there is a column called Updated On - this date field column should remain blank until this claimed returned has been updated. Currently, when an item has been claimed returned, the date in the updated column states 12/31/1969. This date only shows up in the display, it is doesn't show up in the database like this. Looking at other data tables with date columns that are blank - this display is not doing the same thing, such as Aqorders or Purchase Suggestions. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 23409] New: Show borrowernotes and opacnote's lines feeds (staff and opac)
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '20

13 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23409 Bug ID: 23409 Summary: Show borrowernotes and opacnote's lines feeds (staff and opac) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, lines feeds typed in borrowernotes and opacnote are not visible in the interface. Patch is coming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 24688] New: Hold priority isn't adjusted correctly if checking out a middle priority hold
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '20

13 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24688 Bug ID: 24688 Summary: Hold priority isn't adjusted correctly if checking out a middle priority hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To reproduce 1. Place at least four holds on a biblio for different borrowers 2. Check out an item to the 3rd priority borrower 3. Check the existing holds table for the biblio. The priorities might be out of order, or try clicking the dropdowns and there might be an empty dropdown option, or open the browser developer tools and notice the option values in the select are missing value=3. So the priorities have not been adjusted to be consecutive which can cause problems -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 24844] New: Focus on the system preferences searchbar when going to admin home
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '20

13 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24844 Bug ID: 24844 Summary: Focus on the system preferences searchbar when going to admin home Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Every time I go to the Administration main page I have to click into the syspref search bar. Would be nice if I didn't have to do that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11