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

[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

[Bug 11983] code to select patrons to purge needs to be centralized
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11983 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #9 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- I prefer the second approach even if more verbose. It's easier to read and to test. It will certainly be easier to maintain and less error prone. Few remarks: - The having could be replaced with a join, and so more efficient. - filter_by_last_issued sounds wrong. I agree we should have a pattern (here "filter_by_") to explicitly tell what we are doing, but it should also be meaningful. Maybe it is for native English speakers ;) - filter_by_has_issues($options) is not enough explicit IMO. Moreover $options is a boolean, and "issue" must be "checkout". I would suggest: $patrons->filter_by_has_pending_checkouts and another one (?) But maybe I am making things more complicated here. (note: it seems that this subroutine will not be used by cleanborrowers.pl, we do not have this use case) - Should not filter_by_has_issues be filter_by_have_issues? - filter_by_when_expired - the interface allows to filter by "expired before", now we provide a "and/or expire after", but it is not used. It means more code, more tests and so... more potential bugs. It is not a big deal for this one, but we could have filter_by_expired_before that will be easier to read/write/test. Not blocker but worth mentioning/discussing it I think. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21062] New: Clean up borrower_password_recovery when patron is deleted
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21062 Bug ID: 21062 Summary: Clean up borrower_password_recovery when patron is deleted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When a patron is deleted, any entries in borrower_password_recovery should be deleted as well by cascade. CREATE TABLE `borrower_password_recovery` ( `borrowernumber` int(11) NOT NULL, `uuid` varchar(128) COLLATE utf8_unicode_ci NOT NULL, `valid_until` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`borrowernumber`), KEY `borrowernumber` (`borrowernumber`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0