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

[Bug 17091] New: Add AUTOLOAD to Koha::Objects
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '18

05 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17091 Bug ID: 17091 Summary: Add AUTOLOAD to Koha::Objects 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 Up to now if a Koha::Objects based object needs to call DBIx::Class methods, we have to create a new method for Koha::Objects, something like: sub method { my $self = shift; return $self->_resultset->method } To simplify and ease the call to DBIx::Class method, we could create an AUTOLOAD method. -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 16213] New: Allow to select hold's itemtype when using API
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '18

02 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16213 Bug ID: 16213 Summary: Allow to select hold's itemtype when using API Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 13903, 15533 Bug 15533 bring the capability to select an itemtype for a title-level hold in staff and OPAC. This should be possible through the API too. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13903 [Bug 13903] Add API routes to list, create, update, delete reserves https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15533 [Bug 15533] Allow patrons and librarians to select itemtype when placing hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 17682] New: Change URL for Google Scholar in OPACSearchForTitleIn
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '18

02 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17682 Bug ID: 17682 Summary: Change URL for Google Scholar in OPACSearchForTitleIn Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: felix.hemme(a)thulb.uni-jena.de QA Contact: testopia(a)bugs.koha-community.org Google Scholar is no longer accessible via <a href="http://www.scholar.google.com/scholar?q={TITLE}" target="_blank">Google Scholar</a>. It should be changed to the current url <a href="https://scholar.google.com/scholar?q={TITLE}" target="_blank">Google Scholar</a>. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 15876] New: Removing a course-reserved item with no initial shelving location does not revert items.location to NULL
by bugzilla-daemon＠bugs.koha-community.org 01 Feb '18

01 Feb '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15876 Bug ID: 15876 Summary: Removing a course-reserved item with no initial shelving location does not revert items.location to NULL Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org (This happens only when one changes the shelving location while the item is on a course_reserve) Steps to replicate: 1) Find an item with NO shelving location info (ie one that has items.location=items.permanent_location=NULL in the DB and the OPAC/Intranet shows an empty string) 2) Add this item to a course reserve 3) Either when adding the item in the course reserve, or at a later stage CHANGE (from the course reserve screen!) the 'temporary' shelving location info that will be used by that course reserve, by selecting a value from the drop-down list. Let's say 'On Display' 4) Find the item in the OPAC or Intranet, the change is displayed (as expected) 5) REMOVE this specific item from the course reserve 6) Find the item again in the OPAC or Intranet. All the course-reserve related information is reverted back to the original values as expected, except the shelving location, which is NOT reverted back to 'empty'. The old value (in our example 'On Display') is still shown!. FYI, NULL is added from items.location to course_items.location in step 2 as expected However, that NULL value in NOT copied back to items.location or items.permanent_location in step 5 as expected, but instead the value from step 3 is retained. (I have verified this behavior both with 3.20 and 3.22) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 16603] New: When processing uploaded offline circulation file, "apply directly" option fails
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '18

31 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16603 Bug ID: 16603 Summary: When processing uploaded offline circulation file, "apply directly" option fails Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/offline_circ/process_koc.pl OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I have an offline circulation file which was generated by the Windows offline circulation program. If I upload this file and choose "Add to offline circulation queue" it works as expected. If I upload the same file and choose "Apply directly," the process never completes. Firebug shows a seemingly never-ending series of calls to /cgi-bin/koha/tools/background-job-progress.pl?jobID=8c20822320e5fbd7579aa1f61411ba00 but nothing happens. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 17466] New: Show number of outstanding issues when checking in
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '18

18 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17466 Bug ID: 17466 Summary: Show number of outstanding issues when checking in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 17833] New: Memcached silently fails to _initilize_memcached() on the second time it is invoked
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '18

16 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17833 Bug ID: 17833 Summary: Memcached silently fails to _initilize_memcached() on the second time it is invoked 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org When _initilize_memcached() is called the first time, it sets the 'ismemcached'-key and returns 1. When _initilize_memcached() is called the second time, the 'ismemcached'-key already exists and '' is returned (this default to False in Perl). Koha thinks that memcached is not in use and decides to use some other caching mechanism instead. Cache::Memcached::Fast returns undef on server error: https://metacpan.org/pod/Cache::Memcached::Fast#add Koha MUST listen to undefined, instead of False to define whether or not memcached is properly working. Also added simple helpful diagnostics to help identify and log when this memcached server connection problem arises. Here is a small test run to verify this behaviour: root@kohadev:~# echo "fresh memcached start" fresh memcached start root@kohadev:~# perl l.pl 127.0.0.1:4545 1.4.14 (Ubuntu) def : '1' getkey: 'text' root@kohadev:~# echo "val already cached" val already cached root@kohadev:~# perl l.pl 127.0.0.1:4545 1.4.14 (Ubuntu) def : '' getkey: 'text' root@kohadev:~# echo "memcached killed and not responding" memcached killed and not responding root@kohadev:~# perl l.pl undef getkey: '' root@kohadev:~# echo "The return value is undefined" The return value is undefined root@kohadev:~# Here is the code snippet used to test the Memcached-server in the previous example output: kivilahtio@koha_ci_1 /h/k/Koha> cat t.pl use Cache::Memcached::Fast; use Modern::Perl; my $memd = new Cache::Memcached::Fast({ servers => [ '/lxcBindMount/tmp/memcached.sock' ], namespace => 'koha_ci_1:', connect_timeout => 0.2, io_timeout => 0.5, close_on_error => 1, max_failures => 3, failure_timeout => 2, ketama_points => 150, nowait => 1, hash_namespace => 1, }); # Get server versions. my $versions = $memd->server_versions; while (my ($server, $version) = each %$versions) { print "$server $version\n"; } # Store scalars. my $rv = $memd->add('skey', 'text'); print "undef\n" if not defined $rv; print "def : '$rv'\n" if defined $rv; print "getkey: '".$memd->get('skey')."'\n"; -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 17951] New: koha-create should create the template cache dir and configure it in koha-conf.xml
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '18

16 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17951 Bug ID: 17951 Summary: koha-create should create the template cache dir and configure it in koha-conf.xml 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: mirko(a)abunchofthings.net -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 17770] New: t/db_dependent/ Sitemapper.t fails when date changes during test run
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '18

15 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17770 Bug ID: 17770 Summary: t/db_dependent/Sitemapper.t fails when date changes during test run Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: katrin.fischer(a)bsz-bw.de QA Contact: gmcharlt(a)gmail.com (22:48:28) tcohen: we need to fix the test (22:48:34) tcohen: so it mocks the current date t_db_dependent_Sitemapper_t.Its content is valid (369) Failing for the past 1 build (Since Unstable#6 ) Took 0 ms. Error Message not ok 12 - Its content is valid Standard Output 1..16 ok 1 - use Koha::Sitemapper; ok 2 - use Koha::Sitemapper::Writer; ok 3 - add fixtures ok 4 - File sitemapindex.xml created ok 5 - Its content is valid ok 6 - File sitemap0001.xml created ok 7 - Its content is valid ok 8 - File sitemap0001.xml with short URLs created ok 9 - Its content is valid ok 10 - add fixtures ok 11 - File sitemapindex.xml for 75000 bibs created not ok 12 - Its content is valid ok 13 - File sitemap0001.xml created ok 14 - It contains 50000 URLs ok 15 - File sitemap0002.xml created ok 16 - It contains 25000 URLs -- You are receiving this mail because: You are watching all bug changes.

1 42

[Bug 15937] New: Batch checkout buggy behavior
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '18

09 Jan '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15937 Bug ID: 15937 Summary: Batch checkout buggy behavior Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hector.hecaxmmx(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 1920 For damaged items the warning message is not displayed, and Koha let to checkout the item as shown in the image. <https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48411> I notice about a buggy behavior in this functionallity, for example the program let to checkout the first item available without confirm the checkout message, for example, Maxwell's handbook was borrowed/renewed to this patron every time in which I repeat the process. When the process end, you will presented with this table (<https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48412>), one items was checked-out and the others wasn't, but the message is not clear whether those items was checked out or not. Another thing that I could observe is: if circ policies only allow an specific number e.g. two checkouts and two renews of an item the module doesn't let to checkout if patron has one or more checkouts and the message displayed for the program is not clear; If MaxFine is set affect in the checkouts and don't let us checkout as show in the previous image, and as before, the message doesn't provide an adequate information. NOTE: The images presented in this bug, they are obtained by applying bug 15920. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1920 [Bug 1920] Total price not saving to order -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9