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

[Bug 24733] New: Cannot search for duplicate orders using 'Basket created by' field
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24733 Bug ID: 24733 Summary: Cannot search for duplicate orders using 'Basket created by' field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Have an open basket in acquisitions 2 - Add to basket - from an existing order (copy) 3 - Enter a name in the 'Basket created by' field and select a user 4 - Hit search 5 - ISE (Can't use string ("1") as an ARRAY ref while "strict refs" in use at /usr/share/koha/lib/C4/Acquisition.pm line 2482.) -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 21879] New: Code cleaning in printinvoice.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21879 Bug ID: 21879 Summary: Code cleaning in printinvoice.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kohadevinim(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com While working on bug 19489, we realized that some lines are nor necessary anymore, hence we will clean those. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 24732] New: Make DumpTemplateVars more readable
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '20

14 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24732 Bug ID: 24732 Summary: Make DumpTemplateVars more readable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently we just use Dumper output directly, it would be helpful if we formatted things slightly -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[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 13 Apr '20

13 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