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

[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

[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

[Bug 13414] Enable right truncation with search by relevance
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13414 --- Comment #22 from Koha Team Lyon 3 <koha(a)univ-lyon3.fr> --- (In reply to David Cook from comment #21) > (In reply to Fridolin SOMERS from comment #20) > > How is this different from enabling "QueryStemming" ? > > Automatic truncation can lead to huge number of results, consider the > > automatic truncation of author names and short words. > > That's a good question. > > I suppose we'd have to look at how QueryStemming works. At a glance, it only > adds right truncation if it was able to stem the operand I think. > > I think Zebra takes care of manually handling "operand*" type queries... > > So yeah... I don't know about automatic truncation. I think some users > expect it, so they might do a query like "au:fish" and expect to get back > results for "Fishburne" as well as "Fisher". > > If you had QueryStemming on, I doubt "fish" would produce a stemmed operand > since it's already a stem, so that probably wouldn't work unless you had > automatic right truncation. > > That said, I don't know if that's a good thing... I personally think > explicit truncation/wildcarding is a better idea.. Seems that QueryStemming does right truncation even if AutomaticTruncation is disabled provided that QueryWeightField is on example in Lyon3. searching the terms "fonction hypothese" in our OPAC (configured with AutomaticTruncation on, Querystemming and QueryWeightfield off) get 2 results : https://catalogue.univ-lyon3.fr/cgi-bin/koha/opac-detail.pl?biblionumber=37… https://catalogue.univ-lyon3.fr/cgi-bin/koha/opac-detail.pl?biblionumber=57… Note that the term "fonction" exists nowhere as such in the 2 records. In our test instance, with QueryStemming and QueryWeightField on, Autotruncate off, we get these 2 results allthesame. But with QueryStemming on, QueryWeightField and Autotruncate off : no results. Olivier Crouzet -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16744] New: new records not indexed if using a customize Koha Framework
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '16

31 Aug '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16744 Bug ID: 16744 Summary: new records not indexed if using a customize Koha Framework Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 52426 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52426&action=ed… Customize Koha Framework We have identified a possible bug when adding new records using a customize koha framework. If we add a new record with the customize framework, it is not indexed in Koha and not published in the OPAC, if we edit the same record and change the framework to default, the record is indexed and published. >From logs we only see this: tail -f indexer-output.log error retrieving biblio 22947 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 705. We have tested in debian 8 with plack for koha 3.22.5 and 3.22.7, not tested in koha 16.05 Reproduce: 1. Add the OPDF framework to koha 2. Restart plack and restart memcached to make sure everything is clear and ready for work. 3. Add a new record (it can duplicate and existing, new record or import via z39.50 it doesn't matter at all) 4. Save it, it has no effect to add or not add items to biblio. 5. Try to search into koha. 6. check logs tail -f indexer-output.log Regarding the koha framework: there is no tag deleted just tab '-1' for those fields that we do not wish to check. -- You are receiving this mail because: You are watching all bug changes.

1 13