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

[Bug 21495] New: Regression in hold override functionality
by bugzilla-daemon＠bugs.koha-community.org 15 Feb '19

15 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21495 Bug ID: 21495 Summary: Regression in hold override functionality Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The changes made by Bug 11512 causes regression in functionality. That change assumes it is safe to override only tooManyReserves because other holds will not be filled anyway. [The rest is copied from Comment 14 in the bug, explaining our usecase] >From what I can see in the code, this isn't actually true. CheckReserves does not include neither LOST nor WITHDRAWN in its checks. In fact, we use the LOST part here in Gothenburg. When longoverdue.pl marks a book as LOST, our staff adds a reserve to that item, so that they will be notified if it is returned. With the code prior to this patch, this works perfectly fine since we have the AllowHoldPolicyOverride set and returning a LOST item fills the hold. The same logic applies to WITHDRAWN. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 20486] New: Add --marc_conditions option to export_records.pl
by bugzilla-daemon＠bugs.koha-community.org 15 Feb '19

15 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20486 Bug ID: 20486 Summary: Add --marc_conditions option to export_records.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We had the need to filter out certain record based on marc-fields when exporting, so added a --marc_conditions options where filter conditions can be passed to the export script. For example: --marc_conditions="942a=!1". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 18039] New: Move the mandatory and optional files for non-english languages into ' default' directory so bug 17855 permits use of other languages
by bugzilla-daemon＠bugs.koha-community.org 15 Feb '19

15 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18039 Bug ID: 18039 Summary: Move the mandatory and optional files for non-english languages into 'default' directory so bug 17855 permits use of other languages Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 17855 At the moment after applying bug 17855 (updated web installer and onboarding tool) users can only use Koha in English. This bug requires the moving of mandatory and optional files into default directories for all other non-English languages. The rationale for placing the work for this in a bug separate to bug 17855 is that it is going to take a lot of testing to confirm all files have been moved and Koha with the updated web installer and onboarding tool works with other languages. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17855 [Bug 17855] Updated Koha web installer and new onboarding tool feature to guide users through setting up Koha -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 21031] New: Apache Rewrite rules don't work for API when using anything but Debian package Plack configuration
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21031 Bug ID: 21031 Summary: Apache Rewrite rules don't work for API when using anything but Debian package Plack configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au If you install Koha using the Debian packages and you enable Plack, you should be able to reach the API using the following URL: "/api/v1/" If you install Koha using the Debian packages and you don't enable Plack (or you install from source or you're using a git install or whatever else), you can only get the same API response by visiting "/api/v1/app.pl/api/v1/spec" It appears to me that the Rewrite rules in etc/koha-httpd.conf, debian/templates/apache-shared-opac.conf, and debian/templates/apache-shared-intranet.conf don't work. Fixing this doesn't seem quite as easy as just copying over the Apache configuration for Plack-enabled instances, unfortunately, but I'm looking at this... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 18175] New: Makefile sets koha-httpd api path incorrectly for standard installs
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18175 Bug ID: 18175 Summary: Makefile sets koha-httpd api path incorrectly for standard installs Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.sassmannshausen(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When performing a standard (or single) install, Makefile.PL generates an koha-httpd.conf with a hardcoded ../api/$1/app.pl reference. This error causes all REST api routes to fail in a standard/single install context. GET fails with 404, PUT fails with 403. The hard-coded path is correct in the dev context. Switching from an Apache variable to a Makefile variable, and hence replacing the hardcoded ../api bit of the path should fix this. Alex -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 22229] New: Elasticsearch - fields do not have aliases - Koha should always use the common term internally
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22229 Bug ID: 22229 Summary: Elasticsearch - fields do not have aliases - Koha should always use the common term internally Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Target Milestone: --- This problem was discovered in the advanced search - when limiting by shelving location the search is composed as limit=mc-loc:{term} this fails in ES because the index is setup as 'location' What works in both is: limit=location:{term} We either need to build field aliases into ES (https://www.elastic.co/guide/en/elasticsearch/reference/master/alias.html) Or make sure to use consistent names across Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 21146] New: Elasticsearch 5.6+ doesn't consider '0' a valid boolean
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21146 Bug ID: 21146 Summary: Elasticsearch 5.6+ doesn't consider '0' a valid boolean 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: tomascohen(a)gmail.com To reproduce: - Set SearchEngine=Zebra - Run: $ kshell k$ prove prove t/db_dependent/Circulation/Returns.t => SUCCESS: Tests pass! - Set SearchEngine=Elasticsearch - Run: k$ prove prove t/db_dependent/Circulation/Returns.t => FAIL: Things explode because '0' is not a valid boolean for Elasticsearch (legacy fallback in past versions). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 19572] New: opac-result item avaibility not the same as opac-detail shows
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19572 Bug ID: 19572 Summary: opac-result item avaibility not the same as opac-detail shows Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: david.bourgault(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is an issue two of our clients have encountered : the item avaibility in the result page does not match the one in the detail page. e.g.: The items have a notforloan value of -2, which is mapped through Authorised_Values to "In Processing" (or equivalent) but on the OPAC result page, it is displayed as "On Order". The detailed page show the correct value. >From my analysis, this is because whereas the intranet results and the opac details use the database to get items statuses, the opac result goes through the XSLT processing, and doesn't have access to the Authorised_Values table. This is worked around by some hardcoded values in the "item namespace" created by XSLT.pm. It's possible to fix this issue case-by-case for each client, but that's a very ugly solution. I don't plan to submit a patch to this bug, because I am not sure how to solve the issue. (If my explanations are unclear please tell me) -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 17683] New: OPAC_SEARCH_LIMIT no longer accepts group codes as limits
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17683 Bug ID: 17683 Summary: OPAC_SEARCH_LIMIT no longer accepts group codes as limits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: rel_3_16_candidate Severity: trivial Priority: P4 Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gitbot(a)bugs.koha-community.org, gmcharlt(a)gmail.com, paul.poulain(a)biblibre.com Depends on: 10798 SetEnvIf Host "opac2.your-domain.com" OPAC_SEARCH_LIMIT=branch:search_group_code This worked up until recently :( Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10798 [Bug 10798] OPAC_SEARCH_LIMIT behaves badly with search groups -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 21911] New: Scoping OPACs by branch does not work with new library groups
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '19

14 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21911 Bug ID: 21911 Summary: Scoping OPACs by branch does not work with new library groups Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Previously one could scope an OPAC to a specific library group using lines as below in the apache configuration: SetEnv OPAC_SEARCH_LIMIT branch:HCC_GROUP SetEnv OPAC_LIMIT_OVERRIDE 1 RequestHeader add X-Koha-SetEnv "OPAC_SEARCH_LIMIT branch:HCC_GROUP" RequestHeader add X-Koha-SetEnv "OPAC_LIMIT_OVERRIDE 1" This does not work with the new groups system as the groups do not have codes -- You are receiving this mail because: You are watching all bug changes.

1 17