August 2018 - Koha-bugs - lists.koha-community.org

[Bug 19671] New: Circulation wizard / issues_stats.pl does not populate itemtype descriptions correctly
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19671 Bug ID: 19671 Summary: Circulation wizard / issues_stats.pl does not populate itemtype descriptions correctly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Run the circulation wizard with itemtypes as columns, shelving locations as rows - display on screen 2 - Note all itemtype values are blank 3 - Switch rows/columns - same issue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 20177] New: Remove GROUP BY clause in GetCourses
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20177 Bug ID: 20177 Summary: Remove GROUP BY clause in GetCourses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: julian.maurice(a)biblibre.com Blocks: 17258 This bug is a continuation of bug 20144 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17258 [Bug 17258] [OMNIBUS] MySQL 5.7 -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 19204] New: Fines in days restriction calculation is not taking calender into account
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19204 Bug ID: 19204 Summary: Fines in days restriction calculation is not taking calender into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 When using the fines in days feature, the restrictions will be calculated without taking holidays into account. So the restriction can end in the middle of a period the library is closed. To test: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date now is the same and a holiday. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 19579] New: PatronSelfRegistrationEmailMustBeUnique does not prevent duplicates when using PatronSelfRegistrationVerifyByEmail
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19579 Bug ID: 19579 Summary: PatronSelfRegistrationEmailMustBeUnique does not prevent duplicates when using PatronSelfRegistrationVerifyByEmail Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baselibrary.consortium(a)nhs.net QA Contact: testopia(a)bugs.koha-community.org With PatronSelfRegistrationVerifyByEmail set to Require and PatronSelfRegistrationEmailMustBeUnique set to Consider a patron can still self register many times using the same email address. Test case 1. Patron submits self registration form using the same email address 3 times 2. Patron receives 3 verification emails 3. Patron clicks on 3 verify token URLs 4. Staff client now shows the 3 patrons 5. Patron logs into 3 accounts on OPAC 6. Patron cannot change personal details because email address already exists -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 19712] New: Fix command line options of delete_records_via_leader.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19712 Bug ID: 19712 Summary: Fix command line options of delete_records_via_leader.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz 1. This code: 56 if ( $help || !$confirm ) { 57 ... 70 exit(); 71 } means that unless you specify --confirm you will never be able to run the script - it will just print the usage and exit. That means --test is useless. 2. The script has both of these options: -c --confirm: Script will do nothing without this parameter -t --test: Test mode, does not delete records. What happens if you specify both? Or none? I think test mode should be the default (when no options are specified) and changes to the database should only be done when --confirm is specified. This would be consistent with other scripts, I think. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 19972] New: Holds to pull (pendingreserves.pl) should honor syspref " item-level_itypes"
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19972 Bug ID: 19972 Summary: Holds to pull (pendingreserves.pl) should honor syspref "item-level_itypes" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Test plan: 1. Set syspref "item-level_itypes" to "specific item" 2. Create a hold on a record with one item 3. Change the document type of the item 4. Check that the item edition page and the record page show 2 different types. 5. Go to /cgi-bin/koha/circ/pendingreserves.pl 6. Check that the displayed type is the item one 7. Set syspref "item-level_itypes" to "biblio record" 8. Go to /cgi-bin/koha/circ/pendingreserves.pl 9. See that the displayed type is the item one. When the sysopref says "record" This is the bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 16575] New: Irregular behaviour using window.print() followed by window.location.href=
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 Bug ID: 16575 Summary: Irregular behaviour using window.print() followed by window.location.href= 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As we noticed in bug 11014, different browsers handle "window.print()" differently. In the case of window.print() followed by window.location.href=, I've found in IE 11 on Windows 8.1 that the browser changes the window location before the system print dialogue even opens. If I try to mitigate that using the timer from bug 11014, it works in IE and Chrome, but it breaks in Firefox. If I try to use the onafterprint in IE and Firefox, it works in IE but it breaks in Firefox. I started wondering if we even need to be using this window.print() followed by window.location.href= and it occurred to me that we really don't. We should just be using print.css. Patch to follow soon... -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 16653] New: reports/cat_issues_top.pl does not export "Count of checkouts" column as CSV
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16653 Bug ID: 16653 Summary: reports/cat_issues_top.pl does not export "Count of checkouts" column as CSV Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org reports/cat_issues_top.pl does not export "Count of checkouts" column as CSV To replicate: 1/ Make sure that test instance has circulation in a given date range 2/ Go to Home › Reports › Most-circulated items 3/ Select a date range 4/ Select 'To screen into the browser' radio button, click submit. 5/ Note that Columns 'Rank/Biblioitemnumbers', 'Global' and 'Count of checkouts' appear in screen output. 6/ Click the browser's back button 7/ Change output to 'To a file', click submit. 8/ Note that the columns "100/", "Global" and "Total" are exported to the CSV file. "100/" contains the rank, "Global" is still global, and the "Total" column is empty. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15971] New: Allow use of all biblio and biblioitems fields in serial claim letters
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15971 Bug ID: 15971 Summary: Allow use of all biblio and biblioitems fields in serial claim letters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When creating a serial claim letter only title, author and serial are offered as fields in the notice editor. It should be possible to print all fields from the biblio and biblioitems tables including the ISSN in the notices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 16739] New: generate edifact showing on basket groups
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16739 Bug ID: 16739 Summary: generate edifact showing on basket groups Change sponsored?: --- Product: Koha Version: master Hardware: All URL: cgi-bin/koha/acqui/basketgroup.pl?booksellerid=2&close d=1 OS: All Status: Needs Signoff Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: katrin.fischer(a)bsz-bw.de, veron(a)veron.ch CC: veron(a)veron.ch Summary: generate edifact showing on basket groups See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi ?id=6740 See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi ?id=16740 CC: katrin.fischer(a)bsz-bw.de Status: Needs Signoff When looking at basketgroups the 'generate edifact order' button shows even if edi isn't set up for that vendor and leads to a 500 error page --- Comment #1 from Marc Véron <veron(a)veron.ch> --- Duplicate of 6740? --- Comment #2 from Marc Véron <veron(a)veron.ch> --- Sorry, I mean Bug 16740 - EDIFACT on Basket Groups leads to 500 error ( --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- *** Bug 16740 has been marked as a duplicate of this bug. *** --- Comment #4 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Still valid. --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Still valid. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19