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

[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 31 Aug '16

31 Aug '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

[Bug 15503] Grab Item Information from Order Files
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15503 --- Comment #16 from Benjamin Daeuber <bdaeuber(a)cityoffargo.com> --- (In reply to Matthias Meusburger from comment #14) > Benjamin, you were right about the items that were added to all biblios. > Here's a patch that fixes that. > > However, when testing, my budgets are always selected when they exist. In > your case, they are in the dropdown list, but not automatically selected, is > that correct? > You have to use the budget code in your file, and not the budget name. Are > you using the budget code? Mathias, I believe we were using the budget code, yes. We have tested again and now it appears to be mapping properly and creating items properly. Funds are encumbered as expected. However, and this might be tangential, the authorized value does not appear to be updating when either creating the items or receiving them. Currently acquisitions would place a record in an Ordered NOT_LOAN status. This may be a local script, but it does not appear to be syspref. When we create an order using acquisitions in the sandbox, the items appear as available. Additionally, if we do set AcqItemSetSubfieldsWhenReceived in the system preferences, receiving the items does not seem to update the subfields. I know this works in production, but does appear broken here. Additionally, the how is the itype field being populated? If it's not in the record, does it simply list the top item (I notice that it doesn't actually apply the item type when the item is created, but the field is populated in the item import view). -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14060] Remove readonly on date inputs
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14060 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick(a)bywatersolutions.com Status|Signed Off |Failed QA --- Comment #50 from Nick Clemens <nick(a)bywatersolutions.com> --- This all works very well, I can't enter any errors, I can press enter with an invalid date, but it reads it as empty so that seems okay. My one complaint would be that if you click into the datepicker, and decide not to enter a date you should not receive the warning. That is, closing on an empty value should not warn -- You are receiving this mail because: You are watching all bug changes.

1 0