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

[Bug 16008] New: noisy "fatal" warning when new file is moved in another patch
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '16

22 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16008 Bug ID: 16008 Summary: noisy "fatal" warning when new file is moved in another patch Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: QA tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtompset(a)hotmail.com While working on Bug 15870, koha qa test tools gave this error fatal: ambiguous argument 't/db_dependent/RecordProcessor_ViewPolicy.t': unknown revision or path not in the working tree. This is in part, because a test file was moved/renamed and the files changed list includes the old filename. Gracefully handle the file no longer existing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 15824] New: 'Done' button is unclear on batch item modification and deletion
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '16

21 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15824 Bug ID: 15824 Summary: 'Done' button is unclear on batch item modification and deletion Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org To reproduce, go to a biblio record page (ie http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=1) Click edit -> Edit items in a batch Click Save (you don't need to make any changes) Notice Done link at the bottom of the page is not very noticeable. This is the same with batch item deletion as well. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 15759] New: Allow Koha::Object derived objects to be used as hashrefs
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '16

14 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15759 Bug ID: 15759 Summary: Allow Koha::Object derived objects to be used as hashrefs Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On occasion, bugs in Koha have been revealed to be a mis-use of Koha::Object. This seems to be due to our long standing use of hashrefs for data in Koha. For instance, a developer may accidentally write: my $borrowernumber = $borrower->{borrowernumber}; instead of my $borrowernumber = $borrower->borrowernumber; Since our object is a blessed hashref, this does not cause an error. Instead, we just access that key of the hashref, which is almost certainly undefined. With some extra code in Koha/Object.pm, we can allow hashref-like use of our Objects, which will not only prevent these errors, but allow drop-in use of Koha::Objects where we currently use hashrefs! -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 16166] New: Improve L1 cache performance
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '16

08 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16166 Bug ID: 16166 Summary: Improve L1 cache performance 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: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org Bug 16044 introduced two-level caching mechanism to Koha::Cache. By default, get_from_cache() returns a deep copy of the data structures stored in L1 cache (aka "safe mode"). For extremely big and/or complex data structures (like MARC framework hash-of-hashes-of-hashes returned by GetMarcStructure() ), deep-cloning is currently very sub-optimal (i.e., 2-3x slower after Bug 16044); this patch addresses that particular issue. See also: Bug 16044 comments #18 - #23 -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 16076] New: DBIx searches - performance issues
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '16

08 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16076 Bug ID: 16076 Summary: DBIx searches - performance issues 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 While testing Bug 11998 and Bug 15341, I did some quick & dirty comparisons on DBI vs DBIx search performace - how long does it take to fetch from the database: one small system preference (marcflavour) and all system preferences (545 rows). Results: 1) one syspref, DBI: 130 microseconds ( using 'SELECT value FROM systempreferences WHERE variable = ? LIMIT 1') 2) one syspref, DBIx: 1.25 miliseconds ( Koha::Config::SysPrefs->find($var)->value() ) 3) all preferences, DBI: 1.8 miliseconds ( 'SELECT variable, value FROM systempreferences' ) 4) all preferences, DBIx: 21 miliseconds ( Koha::Config::SysPrefs->search()->unblessed(), like in Bug 15341) If I use my $all_prefs_rs = Koha::Config::SysPrefs->search( undef, { columns => [qw/value variable/] } )->unblessed(); in 4), search is a bit quicker (17.1 ms). Maybe it can be improved somehow further, but I don't know how - any ideas? Those numbers may look not very significant at the first glanace, but remember that it's not uncommon for the Koha script to make 2000+ DBI calls (in such cases, they are usually very repetitive - small stuff fetched from uncomplicated tables, over and over again). -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 16278] New: Export.pl Tool needs select all/unselect all boxes for Library section
by bugzilla-daemon＠bugs.koha-community.org 05 Jul '16

05 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16278 Bug ID: 16278 Summary: Export.pl Tool needs select all/unselect all boxes for Library section Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org The export.pl tool needs select all and unselect all boxes for the Library section. Right now, if you're only wanting a certain library's records exported, you have to unchecked lots of boxes (if you're in a multi-branch system). For us, that's 51 boxes to uncheck. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16127] New: Add discharge menu item to patron toolbar
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '16

01 Jul '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16127 Bug ID: 16127 Summary: Add discharge menu item to patron toolbar 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 The patron discharge feature added a "Discharge" tab in the left-hand sidebar menu. I think if we follow views vs. actions guideline (https://wiki.koha-community.org/wiki/Interface_patterns#Views_and_Actions) the link in the sidebar should say "Discharges" (as in view the patron's list of discharges) and there should be menu item in the toolbar (members-toolbar.inc) for the action of discharging the patron. I think this should be added to the "More" drop-down menu. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 16190] New: Enable the indexer daemon by default
by bugzilla-daemon＠bugs.koha-community.org 28 Jun '16

28 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16190 Bug ID: 16190 Summary: Enable the indexer daemon by default Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The indexing daemon is a really cool feature, that there's no reason to have disabled by default. It allows end-users experience almost real-time indexing (with the default 5 seconds frecquency, which could even be lowered). And we have it disabled by default. It prevents queuing too many reindexing actions, and has really low footprint (compared to the cronjob version). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 16044] New: Define a L2 cache for all objects set in cache
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '16

23 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16044 Bug ID: 16044 Summary: Define a L2 cache for all objects set in cache Change sponsored?: --- Product: Koha Version: master 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 Depends on: 11998 I have added a POC on bug 11998 ( patch "Add a L1 cache for sysprefs" ) to use a L1 cache instead of retrieving infos from memcache everytime. If it works for sysprefs, we could use it for any objects set in cache (I have Marc structure and framework in mind). Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11998 [Bug 11998] Syspref caching issues -- You are receiving this mail because: You are watching all bug changes.

1 69

[Bug 16221] New: Use Storable::dclone() instead of Clone::clone() for L1 cache deep-copying mode
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '16

23 Jun '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16221 Bug ID: 16221 Summary: Use Storable::dclone() instead of Clone::clone() for L1 cache deep-copying mode 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: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org Storable dclone() is over 3x faster then Clone::clone() when used for creating a deep copies of the big, complex data structures like MARC frameworks. See also Bug 16044 comments #18 & #20. This is a trivial version of Bug 16166. Performance test results (see Bug 16140 comment #23 for test setup description): # master 146.29 (14.64+14.53+14.51+14.57+14.72+14.56+14.53+15.06+14.56+14.61) # master + patch from this bug report 96.5 (9.77+9.63+9.77+9.77+9.68+9.05+9.68+9.83+9.63+9.69) # master + Bug 16166 90.7 (9.15+9.10+9.16+8.41+9.19+9.19+9.11+9.19+9.02+9.18) Bug 16166 is a bit faster and more comprehensive implementation, but also more complex and harder to test/evaluate. -- You are receiving this mail because: You are watching all bug changes.

1 27