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

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

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15395 --- Comment #31 from Julian Maurice <julian.maurice(a)biblibre.com> --- (In reply to Marc Véron from comment #30) > However it seems that the second part of line 630 in results.tt is no longer > picked for translation or does not translate properly (n available rsp. None > available). I have the impression that the rest of the line after the plural > stuff is skipped. This is expected, quite annoying, but expected. Due to the way the template strings extractor works (not the new one brought by this bug but the current one), almost every change in a template will result in a change in the PO file. For instance, msgid "%s %s %sitems%sitem%s%s, %s available:%s, None available%s %s " will be changed to msgid "%s %s %s%s, %s available:%s, None available%s %s " and will be marked as "fuzzy" so it will not be used. But you can fix the translation, remove the fuzzy flag, and run ./translate install. Text will be translated again. -- 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 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15395 --- Comment #30 from Marc Véron <veron(a)veron.ch> --- Hi Julian I tried again with the tt example from patch 'Bug 15395: Example usage of I18N Template::Toolkit plugin' Followed the test plan (with fr-FR and de-DE), the translations for item/items showed up as expected (exemplaire/exemplaires and Exemplar/Exemplare). Great! However it seems that the second part of line 630 in results.tt is no longer picked for translation or does not translate properly (n available rsp. None available). I have the impression that the rest of the line after the plural stuff is skipped. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5938] Maximum number of issues across a family group
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5938 --- Comment #4 from Lennon Mazonde <lmmazonde(a)gmail.com> --- Hi Katrin, Thanks a lot for responding. What do you suggest i do? Open a new bug request? I've contacted a couple of support companies directly but have had no response. Lennon -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 2454] Don't show credits on Pay Fines Tab
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2454 Felix Hemme <felix.hemme(a)thulb.uni-jena.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion CC| |felix.hemme(a)thulb.uni-jena. | |de --- Comment #4 from Felix Hemme <felix.hemme(a)thulb.uni-jena.de> --- With this patch applied, you can not pay or write off the manual credit. Furthermore, information entered the fields 'barcode', 'description' and 'note' is no longer displayed. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

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

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 --- Comment #103 from Julian Maurice <julian.maurice(a)biblibre.com> --- 5) When I merge 2 authorities on the staff interface, I get a UNIMARC-related error: Unsupported UNIMARC character encoding [] for XML output for UNIMARCAUTH; 100$a -> at /usr/share/perl5/MARC/File/XML.pm line 568. It's triggered by MARC::Record::as_xml in Koha::Authority::MergeRequests::reporting_tag_xml. It seems to work correctly when I add the following code before as_xml: # Copied from AddAuthority my $date = POSIX::strftime("%Y%m%d", localtime); my $defaultfield100 = C4::Context->preference('UNIMARCAuthorityField100'); $newrecord->append_fields( MARC::Field->new('100', ' ', ' ' , 'a'=> $date.$defaultfield100) ); -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5938] Maximum number of issues across a family group
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '17

11 Apr '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5938 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Lennon, this bug report is pretty old already. Usually the "Assignee" gives a clue if someone is actively working on a bug, but in this case it might be a mistake. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

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 #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