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

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 --- Comment #12 from David Cook <dcook(a)prosentient.com.au> --- Using whole records, it would be easy to recover an older version on a timeline. Per field changes would be harder... but you could always load the older version and then do your own diff algorithm for diffing MARC::Record objects... then choose which differences to apply... but that would be work. Actually, a person could look at XML::Diff as well... as that could make computing the difference a lot easier at the field level. Personally, I like the idea of just using the whole record. It's less granular but it would be easier. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14367] History for MARC records. Roll back changes on a timeline or per field.
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14367 --- Comment #11 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Chris from comment #9) > I like the idea of storing history with timestamp and author. But storing > whole record seems like overkill to me. Especially for huge libraries. > > So instead of whole history, just a "delta" of data changed (somewhat git > does) and as mentioned - not JSON but TABLE. After doing some reading, it appears that Git actually does save the whole file during a commit. It will compress it using zlib, but it stores the whole file. However, when it does its garbage collection, it may discard old whole files and replace them with deltas for more efficient storage. Using Compress::Zlib, which is a core Perl module, I compressed a 6.7KB 153 line MARCXML file to 1.3KB. Let's say we have 1,000,000 old versions... that's 976MB or .95GB. Not super huge but not tiny either. If we used GNU diff/patch or even 'git diff --no-index file1 file2', we could get diffs and store those. Using diff, I made a 467B patch for a one line change, and with git diff I got a 474B patch for the same one line change. Presuming 1,000,000 uncompressed patches of the same size, that's 445MB or .434GB. If you compress the patch, you can get it down to 227B, so 216MB or .211GB for 1,000,000 compressed patches. That seems pretty decent to me. So Compress::Zlib is easy to use and it's a core module. Awesome. I think making the deltas may be harder. You can use Git.pm to take advantage of 'git diff --no-index file1 file2', although git diff returns non zero for a diff, so Git.pm actually throws an exception which you have to catch and then you get the diff from there. Not that elegant... plus you'd have to write the records to temporary files (same with using GNU diff). I've seen lots of diff modules on CPAN... and it seems that Text::Diff gets recommended a fair bit (https://metacpan.org/pod/Text::Diff) and shows up in the O'Reilly book it seems (http://docstore.mik.ua/orelly/perl4/cook/ch08_23.htm) I also found it was already installed on my Koha server, although I don't use the Debian packages, so I can't attest to that. It looks like it's required by Test::Differences and that lots of modules use that, so that's probably why it's on my system. I've just tried it out and it's easy to use. Looks like we'd want to use Text::Patch for applying the diff to rebuild a record... although I haven't tried it. Using Text::Diff I got a patch that was 378B uncompressed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 18093] New: Add the Koha::Objects->get_column method
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18093 Bug ID: 18093 Summary: Add the Koha::Objects->get_column method 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 17

[Bug 9988] Leave larger authority merges to merge_authorities cronjob ( pref AuthorityMergeLimit)
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.maurice(a)biblibre.com Status|Signed Off |Failed QA --- Comment #102 from Julian Maurice <julian.maurice(a)biblibre.com> --- QA: I haven't tested it yet, but: 1) koha-qa reports a weird error about Koha::Authority::MergeRequest(s) : $ perl -cw Koha/Authority/MergeRequest.pm Inconsistent hierarchy during C3 merge of class 'Koha::Authority::MergeRequest': current merge results [ Koha::Authority::MergeRequest, ] merging failed on 'Koha::Object' at /usr/share/perl/5.20/parent.pm line 26. BEGIN failed--compilation aborted at /home/koha/env/master/src/Koha/Authority/MergeRequest.pm line 22. Compilation failed in require at /home/koha/env/master/src/Koha/Authority/MergeRequests.pm line 25. BEGIN failed--compilation aborted at /home/koha/env/master/src/Koha/Authority/MergeRequests.pm line 25. Compilation failed in require at Koha/Authority/MergeRequest.pm line 25. BEGIN failed--compilation aborted at Koha/Authority/MergeRequest.pm line 25. It seems to be because of circular dependency between the two modules. If I remove 'use Koha::Authority::MergeRequest;' from Koha::Authority::MergeRequests, there is no error. 2) koha-qa also complains about POD: *** WARNING: empty section in previous paragraph in file Koha/Authority/MergeRequests.pm 3) t/db_dependent/Koha/Authorities.t fails with a UNIMARC setup $ prove t/db_dependent/Koha/Authorities.t [2/8764] t/db_dependent/Koha/Authorities.t .. 1/6 substr outside of string at /usr/share/perl5/MARC/File/XML.pm line 561. Use of uninitialized value $enc in string eq at /usr/share/perl5/MARC/File/XML.pm line 563. Use of uninitialized value $enc in string eq at /usr/share/perl5/MARC/File/XML.pm line 563. Use of uninitialized value $enc in string eq at /usr/share/perl5/MARC/File/XML.pm line 565. Use of uninitialized value $enc in concatenation (.) or string at /usr/share/perl5/MARC/File/XML.pm line 568. # Looks like you planned 4 tests but ran 1. # Failed test 'New merge request, method oldmarc' # at t/db_dependent/Koha/Authorities.t line 97. Unsupported UNIMARC character encoding [] for XML output for UNIMARCAUTH; 100$a -> a at /usr/share/perl5/MARC/File/XML.pm line 568. # Looks like your test exited with 255 just after 4. t/db_dependent/Koha/Authorities.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 3/6 subtests Test Summary Report ------------------- t/db_dependent/Koha/Authorities.t (Wstat: 65280 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 255 Parse errors: Bad plan. You planned 6 tests but ran 4. Files=1, Tests=4, 1 wallclock secs ( 0.01 usr 0.00 sys + 0.84 cusr 0.03 csys = 0.88 CPU) Result: FAIL 4) Koha::Authorities::get_usage_count and Koha::Authorities::linked_biblionumbers look very similar. Is there a real performance gain to use get_usage_count instead of linked_biblionumbers ? C4::Authorities::merge call them both and it looks like we could save one search request by calling only linked_biblionumbers -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11897] Stock Rotation for Koha
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11897 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #52 from Owen Leonard <oleonard(a)myacpl.org> --- Everything was working up until just after adding a list of barcodes to a rota. When I try to go back to 'manage items' I get an error: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /cgi-bin/koha/tools/stockrotation.pl. The log says: [Mon Apr 10 17:50:22.708218 2017] [proxy_http:error] [pid 4055] (20014)Internal error: [client 192.168.50.1:54951] AH01102: error reading status line from remote server httpd-UDS:0, referer: http://kohadev-staff.mylocalkoha.org/cgi-bin/koha/tools/stockrotation.pl [Mon Apr 10 17:50:22.710180 2017] [proxy:error] [pid 4055] [client 192.168.50.1:54951] AH00898: Error reading from remote server returned by /cgi-bin/koha/tools/stockrotation.pl, referer: http://kohadev-staff.mylocalkoha.org/cgi-bin/koha/tools/stockrotation.pl -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15395] Allow correct handling of plural translation
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15395 --- Comment #29 from Julian Maurice <julian.maurice(a)biblibre.com> --- Created attachment 62008 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62008&action=ed… Bug 15395: Make Koha::I18N work with Plack + add tests Language detection was done in a BEGIN block so it was not working correctly with Plack. This is now done when the first translation is requested. This patch also fixes a bug when set_locale(LC_ALL, ...) fails for some reasons (locale is not installed system-wide for example). And finally, add some unit tests Test plan: 1. prove t/Koha/I18N.t 2. Replay the previous test plans with plack enabled -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8426] Diacritics not being mapped for searching
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8426 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #9 from Owen Leonard <oleonard(a)myacpl.org> --- Is this patch still relevant? Comments here are contradictory. If this should still be tested please provide a detailed test plan. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15567] Update API to allow multiple holds for the same record
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15567 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #4 from Owen Leonard <oleonard(a)myacpl.org> --- This looks like it should be marked "Signed off." Please change it if I'm wrong. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 Alex Arnaud <alex.arnaud(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12063] Change date calculation for reserve expiration to skip all holidays
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '17

10 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12063 Alex Arnaud <alex.arnaud(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #61735|0 |1 is obsolete| | --- Comment #65 from Alex Arnaud <alex.arnaud(a)biblibre.com> --- Created attachment 62005 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=62005&action=ed… Bug 12063 - Fix QA failures - Remove expiration date calculation in C4::Letter since it's done when setting the reserve waiting, - remove expiration date calculation in circ/waitingreserves.pl. Use the one in DB, - add a new atomic update that calculate expiration date for waiting reserves, - add tests for days_foward function and fix the infinite loop. -- You are receiving this mail because: You are watching all bug changes.

1 0