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

[Bug 18405] New: Self checkout: Fix broken silent printing
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '18

27 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18405 Bug ID: 18405 Summary: Self checkout: Fix broken silent printing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org Fix broken 'silent printing' (without printer dialog) in self checkout. To reproduce: Set up silent printing to slip printers as described in: https://wiki.koha-community.org/wiki/Setting_up_slip_printer_to_print_silen… Verify that it works for check-outs in staff client. Verify that it does not work in Self checkout. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 17378] New: Add ability to specify maximum number of items per record
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '18

26 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17378 Bug ID: 17378 Summary: Add ability to specify maximum number of items per record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries want to be able to specify a hard limit on the number of items a record can have. It would be nice to have this set per record type, but since most libraries use item level itemtypes, that would make it confusing and non-intuitive. The simplest and most straight forward approach would just be to have a system preference. Koha should then just report that it failed to create an item if the librarian has hit the upper limit specified in the system preference. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 15707] New: Add ability to define hierarchical groups of libraries
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '18

25 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15707 Bug ID: 15707 Summary: Add ability to define hierarchical groups of libraries 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 Koha needs the ability to create hierarchical groups of libraries. This ability could be used in many areas of Koha to make Koha much more flexible and consortium friendly. -- You are receiving this mail because: You are watching all bug changes.

1 276

[Bug 16858] New: import_borrowers.pl does not load because of mysql 5.7
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16858 Bug ID: 16858 Summary: import_borrowers.pl does not load because of mysql 5.7 Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: npm(a)zefanjas.de QA Contact: testopia(a)bugs.koha-community.org The Import Patrons tool does not load on MySQL 5.7 because of the default sql_mode: only_full_group_by. This is the error I got: http://paste.koha-community.org/16 Can't use an undefined value as an ARRAY reference at /usr/lib/x86_64-linux-gnu/perl5/5.22/DBI.pm line 2083 If I change the sql_mode to a mysql 5.6 behavior the import page loads fine. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 17961] New: TT syntax for notices - Prove we have an equivalent for our historical custom syntax
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17961 Bug ID: 17961 Summary: TT syntax for notices - Prove we have an equivalent for our historical custom syntax 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 Blocks: 15278 This bug report is an omnibus. It will link to bug reports which take care of the migration to the TT syntax for notices. For each special marker we have in our historical custom syntax, an equivalence will be provided. Moreover tests will cover all the changes. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 19546] New: Can't locate Mojolicious/Plugin/Koha/REST/Plugin/ Pagination.pm
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19546 Bug ID: 19546 Summary: Can't locate Mojolicious/Plugin/Koha/REST/Plugin/Pagination.pm Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl See bug 19196 and my comment 40. What happened? For just a short time I did not see the error. I merged the last changes on master, ran updatedatabase, restarted plack, flushed the cache and there it was again: Error while loading /etc/koha/plack.psgi: Can't load application from file "api/v1/app.pl": Can't locate Mojolicious/Plugin/Koha/REST/Plugin/Pagination.pm: ./Mojolicious/Plugin/Koha/REST/Plugin/Pagination.pm: Permission denied at (eval 1299) line 1. This effectively breaks opac and staff client completely until I comment the change for the Pagination plugin again in Koha/REST/V1.pm. Note that nothing special happened between Friday and now on this virtual Jessie box.. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 19271] New: Show vendor name instead of internal number on ordered/ spent lists
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19271 Bug ID: 19271 Summary: Show vendor name instead of internal number on ordered/spent lists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The list of ordered and spent amounts for each fund shows only the vendor's internal number instead of the vendor name. This makes the list less useful, especially for printing or exporting. Koha should show the vendor names instead of the numbers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 19223] New: Problem with plugins and encodings
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19223 Bug ID: 19223 Summary: Problem with plugins and encodings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com I have created a couple of plugins for Koha: https://github.com/Libriotech/koha-plugin-overview which queries the Koha database and reports things like number og biblio, items, patrons etc. https://github.com/Libriotech/koha-plugin-btj which receives data from an outside source, saves it to the database, creates records and items and displays some of the data to users. The second one does not show any encoding problems, but the first one does. When I look at /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::No::Libriotech::Overview&method=report&detail=items and have the language set to Norwegian, there are problems with the output from the plugin as well as the other parts of the page, such as the main menu at the very top of the page. I can't see that I have done anything very different in those two plugins, and yet they behave differently. Anyone got a clue if this is a problem with my code or with the plugin system? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 19502] New: Elasticsearch - result sets limited to 10000
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19502 Bug ID: 19502 Summary: Elasticsearch - result sets limited to 10000 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com With the new feature to jump to a last page of search results it is apparent that we can't do this with our current use of ES. The standard limit is 10000 results, it can be increased at the cost of memory - need to look into 'Scroll' or 'Search after' options https://www.elastic.co/guide/en/elasticsearch/reference/5.5/index-modules.h… index.max_result_window The maximum value of from + size for searches to this index. Defaults to 10000. Search requests take heap memory and time proportional to from + size and this limits that memory. See Scroll or Search After for a more efficient alternative to raising this. https://www.elastic.co/guide/en/elasticsearch/reference/5.6/search-request-… https://www.elastic.co/guide/en/elasticsearch/reference/5.6/search-request-… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 19578] New: TT syntax for notices - There is no way to pre-process DB fields
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19578 Bug ID: 19578 Summary: TT syntax for notices - There is no way to pre-process DB fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Jenkins fails (run 287) on a test in t/db_dependent/Letters/TemplateToolkit.t: With the historical syntax: # Your request for an article from tQYRS (c3Av58O0P5xkkIGu) has been canceled for the following reason: With the TT syntax: # Your request for an article from tQYRS_ (c3Av58O0P5xkkIGu) has been canceled for the following reason: The last character of the biblio's title has been removed because it's a punctuation character. It comes from: C4::Letters::_parseletter 893 $val =~ s/\p{P}$// if $val && $table=~/biblio/; The same replacement is done for patron's attributes too. With the TT syntax we retrieve the objects and send them to the template, without fetching the attributes. To restore this behaviour we could apply this regex on all the fields of the biblio objects, but it could be perf killer (we will process fields that we will certainly not used in the template). I thought about the TT filter we could apply on all the variables we display, but we will not know where come from the data, and we need to apply this change only for the biblio table. Any other ideas? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29