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

[Bug 17680] New: C4::Circulation - Replace GetItemIssue with Koha::Issues
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '18

12 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17680 Bug ID: 17680 Summary: C4::Circulation - Replace GetItemIssue with Koha::Issues Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement 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 -- You are receiving this mail because: You are watching all bug changes.

1 92

[Bug 20175] New: Set a correct default value for club_enrollments.date_created
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '18

12 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20175 Bug ID: 20175 Summary: Set a correct default value for club_enrollments.date_created 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 17

[Bug 15439] Current Location incorrect when item in transit
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15439 Lisette Scheer <lisetteslatah(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisetteslatah(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #76559|0 |1 is obsolete| | --- Comment #44 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Created attachment 76866 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76866&action=ed… Bug 7376 Transfer limits should be checked at check-in Test case: * UseBranchTransferLimits must be set * define your branch transfer limit. Refuse transfers from libraryA to libraryB * checkout a book owned by libraryB, from libraryB, with a librarian located at libraryB * move the librarian to libraryA ("Set Library" link top/right) * check-in the book => it's possible whatever your setup After the patch, the behaviour respect the branch transfer limit parameter: you can check-in if you accept transfers, you can't if you refuse them. (Note: IndependantBranches must be OFF, otherwise it's not possible to do the checkin whatever the branch transfer limits) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #43 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- (In reply to Martin Renvoize from comment #42) > Compile time warnings when running the QA script on this I'm afraid.. Looks > like $borrower is returned in the patch but it's not part of the method > signature anymore. Needs more digging.. borrower is indeed defined later in the method but it's not defined before it's called here.. failing qa until that's fixed :( -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #42 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Compile time warnings when running the QA script on this I'm afraid.. Looks like $borrower is returned in the patch but it's not part of the method signature anymore. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8685] Inventory tool fails in timeout with large CB files
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8685 --- Comment #20 from emjhet(a)pa.net --- (In reply to Mike from comment #12) > It is not depend on number of codes, but time that Koha consume to process > them. Think that this is problem with websere timeout time. If it is set on > 600 s (default), problem can be relevant for about 500 - 1000 barcodes. So, > we need solve it by universal way = make Inventory tool improvements that > make processing of barcodes on background, similar like import staging. > Webserver will not wait for it and timeouts will gone. "Small" change can > make Inventory tool really usefu(In reply to Mike from comment #12) > It is not depend on number of codes, but time that Koha consume to process > them. Think that this is problem with websere timeout time. If it is set on > 600 s (default), problem can be relevant for about 500 - 1000 barcodes. So, > we need solve it by universal way = make Inventory tool improvements that > make processing of barcodes on background, similar like import staging. > Webserver will not wait for it and timeouts will gone. "Small" change can > make Inventory tool really usefull. So is this still a problem in Koha 17.11.06? I don't want to take the time to scan thousands of items just to have it not work (again.) I believe I was using 17.05 the last time it did not work. What do we need to do to get the results from the inventory process? Not having this ability really limits the usefulness of Koha. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21039] New: auth_show_hidden_data.pl should also check if the subfield is ignore
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21039 Bug ID: 21039 Summary: auth_show_hidden_data.pl should also check if the subfield is ignore Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Because after testing, an ignored subfield looses it's data when editing and saving. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18811] New: Visibility settings inconsistent between framework and authority editor
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18811 Bug ID: 18811 Summary: Visibility settings inconsistent between framework and authority editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: Needs Signoff Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: m.de.rooy(a)rijksmuseum.nl Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, julian.maurice(a)biblibre.com, nick(a)bywatersolutions.com Blocks: 17380 Status: ASSIGNED Assignee: m.de.rooy(a)rijksmuseum.nl CC: jonathan.druart(a)bugs.koha-community.org, julian.maurice(a)biblibre.com, nick(a)bywatersolutions.com Status: Needs Signoff Patch complexity: Small patch Blocks: 17380 >From Nick Clemens on IRC: "Worth mentioning - you can't edit the 942 of an authority when creating, but it appears you can when editing, though you can't save it - confusing as end user." We should keep in mind that AddAuthority overwrites 942c when adding or modifying auth records. When adding a record: Since you choose the framework, we should not allow to change 942c here. The current behavior is fine; the field should normally be hidden via the framework. (We could even enforce it if it would not be hidden?) When modifying a record: The authorities.pl script (incorrectly) shows hidden fields when filled (which actually is weird). Since 942c is overwritten, this is useless. A closer look reveals that the visibility checks in authorities.pl do not completely correspond with the values used in auth_subfields_structure.pl. Auth_subfields_structure offers only two possibilities: 0=Show all and -5=Hide all. The code in authorities.pl now checks <=-4 or >=5 (probably remains from older code). Note that the sql install scripts initialize 942c to 8. The proposed patch adds more consistency between auth_subfields_structure.pl and authorities.pl. A non-zero value will be interpreted as hidden. IMPORTANT NOTE: This solution will remove values in hidden fields from the MARC record. Imo it is theoretically the best solution, but if we do not want to take that risk, we could also remove the two next statements at line 407 and 423 and add a specific next for 942c (enforcing to always hide it). --- Comment #1 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- In the previous comment 942c must be 942a. --- Comment #2 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 64314 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64314&action=ed… Bug 18811: Change visibility checks in authorities.pl The check is now <=-4 or >=5, but the framework uses 0 for Show all and -5 for Hide all. (Note that sql installer scripts also use 8.) When modifying an authority, the script also showed hidden fields when filled, since it did not check the hidden field but only the tab field. NOTE: The proposed solution restores consistency, but will remove hidden fields from the MARC record. Test plan: [1] Set field 942a to Show all in an authority framework. [2] Open a new record in this framework and verify that you see 942a. [3] Edit an existing record in this framework and verify again. [4] Set field 942a now to Hide all in this framework. [5] Open a new record in this framework and verify that 942a is hidden. [6] Edit an existing record in this framework and verify again. --- Comment #3 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Nick, Julian or Jonathan: Would you have any comment on the *risk* of this solution? --- Comment #4 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #3) > Nick, Julian or Jonathan: > Would you have any comment on the *risk* of this solution? This mail did not come through due to a mail problem that specific day. Second try :) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17380 [Bug 17380] Cannot edit authorities with authtypecode = default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46