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

[Bug 11039] SIP Server responds with valid CHECKIN to SC but fails to checkin item on Koha
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11039 --- Comment #2 from Colin Campbell <colin.campbell(a)ptfs-europe.com> --- I managed to reproduce this when Barry first reported it. But rerunning the test script I used then against master the buggy behaviour does not occur, nor with the current 3.22 and 3.20 releases. I wonder if a subsequent patch to C4/Circulation or the ILS routines has rectified this as a side effect -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15935] New: Provide koha-cleanup-database command for package install
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15935 Bug ID: 15935 Summary: Provide koha-cleanup-database command for package install Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: library(a)stas.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We have provided commands for the most important command line actions for package users, but there are yet several important commands which require calling the .pl file directly. The commands provided by the packages take into account the location of koha-conf.xml and perl files for the instance provided or detected, but do not seem to use the environmental variable KOHA_CONF and PERL5LIB directly. As a result it seems that the Debian/Ubuntu packages do not presently set up these environmental variables. On package installs executing the commands not yet provided for requires manually setting these variables. For instance, when trying to run the cleanup_database.pl utility on a package install it will fail because KOHA_CONF is not specified. To allow it to work one must manually set this variable. I propose the creation a command for the package installs called "koha-cleanup-database" which will avoid the use of environmental variables, but provide for package users the ability to cleanup their databases. I propose this utility because of its value -- we have been cataloging a 40,000 volume library and from all the z39.50 searches our database had reached over 1.5 GB. On the non-package install we cleaned up the database down to only 120 MB by removing the old z39.50 searches and the whole setup is much more stable and fast. Upgrading to a package install on a new server, we have lost this functionality. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 15954] New: Availability issue after entering 856 electronic links
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15954 Bug ID: 15954 Summary: Availability issue after entering 856 electronic links Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: willem(a)cfce.org.za QA Contact: testopia(a)bugs.koha-community.org When I've entered a biblio and item, the page opac-search.pl reflects correctly the Availability of the object (ie. Copies available at xxx). However, as soon as I add 856 field info about electronic accessibility, the availability info disappears. Still, after clicking on the specific item, opac-detail.pl shows the availability of items correctly. I can also still filter on availability in opac-search.pl, although it doesn't show that the things are available, it correctly filters the available items. It doesn't occur as a known issue. Am I the first person with this problem? I'm using koha 3.00 Thanks, Willem -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 11285] Vocabulary disambiguation
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11285 --- Comment #23 from Josef Moravec <josef.moravec(a)gmail.com> --- I faced up another ambigous term: "Order" in acquisition "Order" as sort order - modification templates (and maybe more) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14168] enhance streaming cataloging to include youtube
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14168 --- Comment #20 from Josef Moravec <josef.moravec(a)gmail.com> --- Created attachment 48542 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48542&action=ed… Bug 14168 - Followup: make module WWW::YouTube::Download required Module C4::HTML5Media is used in detail.pl, so if you don't have installled module for YouTube, you get an internal server error. This patch make module WWW::YouTube::Download required and adds it to package dependencies Test plan: 1. Don't have installed module WWW::YouTube:Download, neither package libwww-youtube-download-perl 2. Try to access biblio detail in staff client (detail.pl) - you'll be presented withh internal server error 3. Check the About page -> Perl modules, the WWW::YouTube::Download should be reported as missing optional 4. Apply the patch 5. Check the About page -> Perl modules, the WWW::YouTube::Download should now be reported as missing required 6. Create and install debian package, the libwww-youtube-download-perl should be the dependency and so installed with koha-common package (use apt-get install -f, if neccessery) 7. Check the About page -> Perl modules, the WWW::YouTube::Download should now be reported as Module current 8. Try to access biblio detail in staff client (detail.pl) - it should be display, no error now -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12478] Elasticsearch support for Koha
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478 --- Comment #200 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- And I would also like to know who has already looked at the ES implementation and get their feedbacks. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12478] Elasticsearch support for Koha
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478 --- Comment #199 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- I would like to get other opinions on the discussion on comment 38 and comment 39 about the idea to reuse existing search scripts and templates. IMO it will be a mess in a near future: 1/ we will want to implement things for ES, not supported by Zebra 2/ at some point the features already implemented for Zebra won't be available for ES => We will have to write switch (if se=='es' {} elsif se == 'zebra') everywhere. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12478] Elasticsearch support for Koha
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478 --- Comment #198 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- We should avoid to repeat the Solr problem - I think part of the problem was that it was not production ready when included in Koha and I'd hate to see us get stuck in a similar way with ES. I think some good information/documentation about what works and what works not (yet) would be good. I am thinking about a wiki page - with more end user oriented information - which system preferences are supported, why does a search x result in y...(FAQ?), how to configure in the GUI, and fill in any gaps while testing. I could start a page, but will need help filling in the information and also to get ES running on my computer. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15350] DBIx::Class Startup speed
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15350 --- Comment #4 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Jesse Weaver from comment #3) > Created attachment 48519 [details] [review] > Bug 15350: Cache loaded DBIx::Class schema classes > > This separates the Koha::Schema creation into two stages: > > 1) The loading of the schemas themselves, which is done upon import of > Koha::Database. This requires moving the import of Koha::Schema from > an on-demand `require` to just a `use`; most everything in Koha uses > C4::Context, which will indirectly end up calling > Koha::Database->schema->new anyway, so this was no longer saving > anything. Yes, I totally agree. This was previously done when our Plack implementation was not considered stable and we did not want to load the schema everywhere. Now we want. > 2) The actual database connection, which is done by cloning the schema > created above and adding a database connection. I am not sure about this change, the Koha::Schema->connect will load all the classes (see Koha::Schema: 12 __PACKAGE__->load_namespaces;). > Note that this saves time only when a Plack-based Koha needs to create > a database connection, which is usually only the case for a new worker. > > Unscientific timings before patch: > * First load of koha2marclinks.pl on a new worker: 0.70 seconds > * Each load after: 0.17 seconds > > After patch: > * First load: 0.31 seconds > * Each load after: 0.17 seconds Are you sure it's brought by the ->clone call or just the move from require to use? :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12478] Elasticsearch support for Koha
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '16

02 Mar '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478 --- Comment #197 from Mirko Tietgen <mirko(a)abunchofthings.net> --- I think we should try to get it in and explicitly mark it as experimental. That would give interested (non-dev) parties the chance to try it and give feedback. I have spoken to a lot of people about Koha recently, and being able to test ES during their evaluation of the system would likely help some of them to make a decision in favour of Koha. -- You are receiving this mail because: You are watching all bug changes.

1 0