July 2017 - Koha-bugs - lists.koha-community.org

[Bug 18966] New: Move of checkouts - Deal with duplicate IDs at DBMS level
by bugzilla-daemon＠bugs.koha-community.org 14 Sep '17

14 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18966 Bug ID: 18966 Summary: Move of checkouts - Deal with duplicate IDs at DBMS level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: blocker 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 Depends on: 18651, 18931 Koha suffers of big bugs due to its history: When data are deleted, they are moved to another tables. For instance issues and old_issues: when a checkin is done, it is moved to the old_issues table. That leads to a main problem that is described on https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix However we tried first to fix the problem (for issues/old_issues) at code level on bug 18242. The goal was to prevent data lost. Data lost may happens in this case: Check an item out (issue_id = 1) Check an item in (issue_id = 1) Restart MySQL (reset auto increment for issue_id to 1) Check an item out (issue_id = 1) Check an item in => BOOM, the issue_id is a PK in old_issues and the move fails. Before bug 18242 the data were lost, we inserted the value into old_issues, which fails silently (because of RaiseError set to 0 in Koha::Database), then delete the row from issues. That has been fixed using a transaction. This patch introduced a regression we tried to fix on bug 18651 comment 0, the patron was charged even if the checkin was rejected. A good way to fix that would have been to LOCK the tables: 1- Start a transaction 2- LOCK the table to make sure nobody will read id and avoid race conditions 3- Move the content from one table to the other, dealing with ids 4- UNLOCK the table 5- Commit the transaction But there were problems using LOCK and DBIx::Class (See commit 905572910b3a - Do no LOCK/UNLOCK the table). Finally the solution implemented is not acceptable for several reasons: - batch checkins may fail - issue_id will always stay out of sync (between issues and old_issues) See 18651 comment 66. Since the next stable releases are very soon, and we absolutely need to fix this problem, I am suggesting to: 1- Execute the move in a transaction to avoid data lost and reject the checkin if we face IDs dup => It will only reject 1 checkin (max is 1 * MySQL restart), no need to deal with race conditions, 2- Display a warning on the checkin page and link to a solution/explanation 3- Communicate as much as we can on the proper fix: Update auto increment values when the DBMS is restarted - https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix 4- Display a warning on the about page for corrupted data (see bug 18931) 5- Write and make available a maintenance script to fix corrupted data (TODO LATER) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18651 [Bug 18651] Move of checkouts is still not correctly handled https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18931 [Bug 18931] Add a "data corrupted" section on the about page -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 17784] New: Ability to see funds with an amount of 0.00 when doing a new order
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '17

12 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17784 Bug ID: 17784 Summary: Ability to see funds with an amount of 0.00 when doing a new order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org In the acquisition module, funds with an amount of 0.00$ don’t appear in the dropdown list when doing an new order (in accounting details). To do that, we must put 0.01$ to be able to see the information. Here is the link : cgi-bin/koha/acqui/neworderempty.pl Can we add an option to put funds active or inactive to manage them correctly (and see them in the dropdown list) ? This is usefull to some librairies which must receipt and treat documents for another service through a bigger organization. This other service is in charge of the payment. The document must be present in the list to help librairians to make the follow-up with it. Thanks, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 17747] New: Missing extension name .t: /t/db_dependent/ Koha_Elasticsearch.
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '17

12 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17747 Bug ID: 17747 Summary: Missing extension name .t: /t/db_dependent/Koha_Elasticsearch. Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: faceker(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16942] New: Confirm hold results in ugly error
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '17

12 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16942 Bug ID: 16942 Summary: Confirm hold results in ugly error Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Confirming a hold to set it to waiting will result in an DBIC error in master. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 16493] New: acq matching on title and author
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '17

12 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16493 Bug ID: 16493 Summary: acq matching on title and author Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: critical 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 When you order from a staged file you're getting duplicate warnings that are inaccurate. For example, when you order a file of 50 DVDs for example and they don't have ISBNs they're matching on the books. And then you have to order them one by one. ---------- [11:42] <cait> it seems to use FindDuplicate [11:43] <cait> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=C4/Search.pm;hb=4… [11:44] <cait> i might be misreading it, but looks like isbn when there is one - if there is none, title and author ----------- This shouldn't happen, it's a big deal in libraries that do a lot of ordering and is just plain wrong based on cataloging rules. Is there any way to override this without doing them one by one or a way to make it use the matching rules instead? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 18476] New: Article requests are missing from the manual.
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '17

12 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18476 Bug ID: 18476 Summary: Article requests are missing from the manual. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: nengard(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org There is no documentation on article requests in the manual. This was added in bug 14610 -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 18876] New: Broken links in Koha documentation
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '17

12 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18876 Bug ID: 18876 Summary: Broken links in Koha documentation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: pablo.bianchi(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 64711 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64711&action=ed… linkchecker-gui output report in XML, CSV and HTML. I found some broken links in Koha documentation, particularly related to fragments (AKA in-page, local) links, within same HTML. For example on [Tools section](https://koha-community.org/manual/17.05/html/03_tools.html), the left side table of contents correctly point to #marc-modification-templates fragment, but in some partes and itself on the title incorrectly point to non-existent #marcmodtemplates. This is very annoying while reading documentation. I couldn't find a way to list all broken in-page links. I tried: + http://validator.w3.org/checklink + wget --spider -o wget.log -e robots=off --wait 1 -r -p https://koha-community.org/manual/17.05/html/ + linkchecker-gui + https://www.npmjs.com/package/broken-link-checker `blc https://koha-community.org/manual/17.05/html/ -roe` Attached to this bug the linkchecker-gui results using [this](https://koha-community.org/manual/17.05/html/) as starting URL. It found 231 broken URLs, but not local ones. PS: Markdown on this bugzilla would be great. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 16510] New: When record items exceed OpacMaxItemsToDisplay opacSerialDefaultTab is ignored
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '17

11 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16510 Bug ID: 16510 Summary: When record items exceed OpacMaxItemsToDisplay opacSerialDefaultTab is ignored Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In opac-detail.pl the if construct checks (@itemloop) to see if holdings should be displayed, however, if items exceed OpacMaxItemsToDisplay @itemloop isn't populated and the syspref is ignored my $opac_serial_default = C4::Context->preference('opacSerialDefaultTab'); my $defaulttab = $opac_serial_default eq 'subscriptions' && $subscriptionsnumber ? 'subscriptions' : $opac_serial_default eq 'serialcollection' && @serialcollections > 0 ? 'serialcollection' : $opac_serial_default eq 'holdings' && scalar (@itemloop) > 0 ? 'holdings' : $subscriptionsnumber ? 'subscriptions' : @serialcollections > 0 ? 'serialcollection' : 'subscriptions'; $template->param('defaulttab' => $defaulttab); -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 18154] New: Show card number in detailled suggestion pages
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '17

11 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18154 Bug ID: 18154 Summary: Show card number in detailled suggestion pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Someone in our network is asking if we can add user card number in detailled infos page of a suggestion. It's because some schools print this page for administrative procedures once the book is bought. 1) Go to staff client interface 2) Go to Acquisitions 3) Clic on "suggestions" on the left 4) Observe that all infos on the asking person appears there (name, card number and membership date) 5) Clic on a suggestion ("show suggestion #XXXX") 6) Observe that all info on the person still there except his card number Thanks for helping, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16130] New: Show the item non-public note on the detail view
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '17

11 Sep '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16130 Bug ID: 16130 Summary: Show the item non-public note on the detail view Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We aren't showing the nonpublic note in the intranet detail view. It's useful to have there, so we should show it! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12