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

[Bug 20139] New: Improve MARC mapping translatable strings
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20139 Bug ID: 20139 Summary: Improve MARC mapping translatable strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr There's one untranslatable error message, and couple other messages that are annoying to translate due to using concatenation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 20151] New: Search is broken when stemming has no language
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20151 Bug ID: 20151 Summary: Search is broken when stemming has no language Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When stemming is enable in catalog searching, C4::Search::_build_stemmed_operand will transform operand into stemmed operand using stemmer Lingua::Stem::Snowball with a specified language. This stemmer returns undef is no language is defined. In classic catalog search, current language is used. But in other pages acqui/neworderbiblio.pl and cataloguing/addbooks.pl no language is defined so operand is empty. Any search returns entire catalog. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[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