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

[Bug 17188] New: Koha does not support several memcached servers
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '16

05 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17188 Bug ID: 17188 Summary: Koha does not support several memcached servers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal 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 There is a bug in the initialisation of memcached, the server string is not correctly parsed. If several memcached servers are defined, they are separated by commas and so the string should be split accordingly. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 17225] New: Search using ISBN13 should find ISBN10 (and vice versa).
by bugzilla-daemon＠bugs.koha-community.org 04 Sep '16

04 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17225 Bug ID: 17225 Summary: Search using ISBN13 should find ISBN10 (and vice versa). Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org We would like to see functionality developed to allow a search using the 13 digit form of the ISBN find the matching 10 digit ISBN (and vice versa) when the other length ISBN is not in the record. We accept that if both the 13 digit and 10 digit ISBN were present in the record then the record would be found whether we entered the 10 or the 13 digit ISBN. An example search is 9780500280775, where we expect to find the record with (only) the ISBN of 0500280770 already in the record. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16549] New: Remove the use of "onclick" from header search forms
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '16

02 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16549 Bug ID: 16549 Summary: Remove the use of "onclick" from header search forms Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED 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 header search forms use "onclick" to trigger the "keep_text()" function. This functionality can be moved to the globally-included js file. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 --- Comment #48 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 55089 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55089&action=ed… Bug 14868: (QA followup) POD fixes To make the QA scripts happy, the POD needed a fix, and also keys applied to a hashref needs to be avoided. Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 --- Comment #47 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 55088 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55088&action=ed… Bug 14868: (QA followup) Change permission check order This patch changes the permission check order because haspermission is the smaller check, and going through the patron/user and its guaranteed before checking if it is (say) a staff member or even a superlibrarian doesn't seem right. Bonus: Remove unneeded C4::Auth import in Patron.pm Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #54897|0 |1 is obsolete| | --- Comment #46 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 55087 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55087&action=ed… Bug 14868: Display required permissions in permission error response When user does not have required permissions to use API operation, it would be useful to let them know which permissions he is missing. Since they are now defined in Swagger, we can easily render them into the response. To test: 1. Use a patron without any permissions 2. Make GET request to http://yourlib/api/v1/patrons 3. Observe permission error and see that required_permissions are displayed. 4. Run t/db_dependent/api/v1/patrons.t Signed-off-by: Benjamin Rokseth <benjamin.rokseth(a)kul.oslo.kommune.no> Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #54896|0 |1 is obsolete| | --- Comment #45 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 55086 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55086&action=ed… Bug 14868: Use x-koha-authorization in current routes To test: 1. Run t/db_dependent/api/v1/holds.t 2. Run t/db_dependent/api/v1/patrons.t Signed-off-by: Benjamin Rokseth <benjamin.rokseth(a)kul.oslo.kommune.no> Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #54895|0 |1 is obsolete| | --- Comment #44 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 55085 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55085&action=ed… Bug 14868: Give users possibility to request their own object Allow access to user's own objects even if they do not have required permissions. This will be very useful in many cases where an user wants to request their own object, for example renewing their checkouts or placing a hold for themselves. First, this patch renames "x-koha-permission" to "x-koha-authorization" in order to describe the new functionality better. Second, we can now add two extra parameters under "x-koha-authorization": - "allow-owner"; Allows the owner of object to access it (without permission) - "allow-guarantor"; Allows guarantor of the owner of object to access it (without permission) Third, since permission checking is outside of actual controller, we need a way to find out ownership from different types of parameters, e.g. checkout_id from /checkouts/{checkout_id}, borrowernumber from /patrons/{borrowernumber} etc. A solution is to match the parameter with a subroutine that is designed to verify the ownership for that object. See the new subroutines in Koha::REST::V1. To use this functionality you will simply define it in Swagger: "/patrons/{borrowernumber}": { "get": { ..., "x-koha-authorization": { "allow-owner": true, "permissions": { "borrowers": "1" } } } } If a parameter that is not yet defined in Koha::REST::V1::check_object_ownership, you also need to define it and implement a subroutine that determines ownership. Tests are provided in a following patch that adds this functionality for current API operations. Signed-off-by: Benjamin Rokseth <benjamin.rokseth(a)kul.oslo.kommune.no> Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14868] REST API: Swagger2-driven permission checking
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #54894|0 |1 is obsolete| | --- Comment #43 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 55084 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55084&action=ed… Bug 14868: Swagger2-driven Permission checking Define 'x-koha-permission' for the Swagger2 Operation Object, to automatically authorize against the required permissions. This way we immediately tell the API consumer in the Swagger2-definition, which permissions are needed to access defined resources. Also we don't need to maintain permissions in multiple locations and we can build a smart testing framework to help a lot in creating tests for the new REST API. Signed-off-by: Benjamin Rokseth <benjamin.rokseth(a)kul.oslo.kommune.no> Signed-off-by: Tomas Cohen Arazi <tomascohen(a)theke.io> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13445] Scheduled Report, Type=URL fails
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '16

01 Sep '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13445 Eric Phetteplace <ephetteplace(a)cca.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ephetteplace(a)cca.edu --- Comment #3 from Eric Phetteplace <ephetteplace(a)cca.edu> --- I agree strongly with Katrin that it's a bad idea to leave broken features in the UI. This doesn't work as advertised and should be removed. I'm perfectly willing to write a patch and removes the <select> from the scheduler.tt template, replacing it with a hidden input, and the corresponding help text in corresponding template as well if people are agreed that that's the best course of action. While this may be a useful feature I think it's better to remove the broken appendage of it first and add back if/when it's fully complete. It's also already possible to construct a link that goes to the results of a particular report. One could create a calendar reminder in some external application that handles this use case easily. -- You are receiving this mail because: You are watching all bug changes.

1 0