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

[Bug 15682] New: Merging records from cataloguing search only allows to merge 2 records
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '16

19 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15682 Bug ID: 15682 Summary: Merging records from cataloguing search only allows to merge 2 records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When merging from the list, you can now merge multiple records. But when merging from the cataloguing search, a javascript alert tells you that only 2 records can be selected for merging. Obviously... both should work the same and allow for multiple records to be merged at once. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 16088] New: Excessive CGI->new() calls hurting cache performace under plack
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '16

18 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16088 Bug ID: 16088 Summary: Excessive CGI->new() calls hurting cache performace under plack Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org Under plack, CGI->new is overriden (in misc/plack/koha.psgi etc.) - we are flushing L1 syspref cache in there. C4::Language::getlanguage() subroutine calls CGI->new().. Problem is, getlanguage() is getting called surprisingly often in Koha (e.g., ~100 times per single catalogue search), and that hurts syspref caching performance under plack very significantly. -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 16165] New: Include link to ILS-DI documentation page in ILS-DI system preference
by bugzilla-daemon＠bugs.koha-community.org 16 Jun '16

16 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16165 Bug ID: 16165 Summary: Include link to ILS-DI documentation page in ILS-DI system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There is no clue in the system preference about the nice ILS-DI documentation once you turn it on. We should include a note and the link, similar to how we do it for the web self checkout. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 15927] New: Remove use of <tr class="highlight"> for alternating row colors.
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '16

15 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15927 Bug ID: 15927 Summary: Remove use of <tr class="highlight"> for alternating row colors. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org As a follow-up to the changes made in Bug 2889 we should clean up template which have markup like this: [% IF ( books_loo.toggle ) %] <tr class="highlight"> [% ELSE %] <tr> [% END %] ...with the goal of being able to remove the "highlight" class from staff-global.css or re-purpose it for a more specific highlighting task. staff-global.css line 267, "tbody tr:nth-child(odd) td" should eliminate the need for the highlight class. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 16005] New: Standardize use of icons for delete and cancel operations
by bugzilla-daemon＠bugs.koha-community.org 15 Jun '16

15 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16005 Bug ID: 16005 Summary: Standardize use of icons for delete and cancel operations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Right now we are using a mix of similar icons for operations like delete, cancel, close, etc. We need to set a standard so that it is clear which icon means what. I propose that the "trash" icon be used anywhere something is being deleted, removed, or cleared: http://fortawesome.github.io/Font-Awesome/icon/trash/ I propose that we use the "times" (for which "remove" is an alias) icon for cancel operations (where buttons are used): http://fortawesome.github.io/Font-Awesome/icon/times/ I propose that we use the "times-circle" icon to mean "close:" http://fortawesome.github.io/Font-Awesome/icon/times-circle/ -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 15823] New: Can still access patron discharge slip without having the syspref on - Permissions breach
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '16

06 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15823 Bug ID: 15823 Summary: Can still access patron discharge slip without having the syspref on - Permissions breach Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To reproduce: Ensure that useDischarge syspref is off. Go to cgi-bin/koha/members/discharge.pl?borrowernumber=X Confirm that you are still able to access this page and generate discharge slip. This is a permissions breach -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 15939] New: modification logs view now silently defaults to only current day's actions
by bugzilla-daemon＠bugs.koha-community.org 31 May '16

31 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15939 Bug ID: 15939 Summary: modification logs view now silently defaults to only current day's actions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When accessing the modification logs from a link that does not explicitly set the to and from dates (e.g., from patron or bib details), no results are displayed unless the object had an action occur during the current day. This is a side-effect of commit 5dceb851 for bug 13813: In C4/Log.pm: - my $iso_datefrom = C4::Dates->new($datefrom,C4::Context->preference("dateformat"))->output('iso'); - my $iso_dateto = C4::Dates->new($dateto,C4::Context->preference("dateformat"))->output('iso'); + my $iso_datefrom = output_pref({ dt => dt_from_string( $datefrom ), dateformat => 'iso', dateonly => 1 }); + my $iso_dateto = output_pref({ dt => dt_from_string( $dateto ), dateformat => 'iso', dateonly => 1 }); In particular, C4::Dates->new($foo... returns undefined if $foo is undefined, whereas output_pref({ dt => dt_from_string( $foo... returns the current date. This amounts to a regression. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 15964] New: Cannot view detail bib record because missing perl module WWW::YouTube::Download
by bugzilla-daemon＠bugs.koha-community.org 25 May '16

25 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15964 Bug ID: 15964 Summary: Cannot view detail bib record because missing perl module WWW::YouTube::Download Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hector.hecaxmmx(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl WWW::YouTube::Download needs to be marked as required -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 15878] New: C4::Barcodes::hbyymmincr should have/require a default branch or provide an error
by bugzilla-daemon＠bugs.koha-community.org 25 May '16

25 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15878 Bug ID: 15878 Summary: C4::Barcodes::hbyymmincr should have/require a default branch or provide an error Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When creating a new hbyymmincr barcode no branch is used if none is passed in. If the format requires hb=homebranch it shouldn't be able to be created without one. To recreate: 1 - prove -v t/db_dependent/Barcodes.t 2 - observe that in output above no hb component is found in the generated barcodes This works in cataloguing/value_builder/barcode.pl because a branchcode is passed -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 15877] New: C4::Barcodes does not correctly calculate db_max for 'annual' barcodes
by bugzilla-daemon＠bugs.koha-community.org 25 May '16

25 May '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15877 Bug ID: 15877 Summary: C4::Barcodes does not correctly calculate db_max for 'annual' barcodes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The SQL query to find the database max value for annual barcodes is: 42 my $query = "SELECT max(substring_index(barcode,'-',-1)) AS chunk,barcode FROM items WHERE barcode LIKE ? GROUP BY barcode"; 43 # FIXME: unreasonably expensive query on large datasets The 'max' in the first column creates confusion and disrupts the normal pairing of the db. To recreate: 1 - Add two 'annual' type barcodes to the system (2016-0003, 2016-0006) 2 - Run the query: SELECT max(substring_index(barcode,'-',-1)) AS chunk,barcode FROM items WHERE barcode LIKE '2016-%' GROUP BY barcode 3 - Note that returned values may not pair up, in my case I got things like: chunk | barcode 0006 | 2016-0003 -- You are receiving this mail because: You are watching all bug changes.

1 24