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

[Bug 15504] Track Patron's Last Activity
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 --- Comment #197 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- See 35231. OPAC is blocked when logging out. Did we miss an Auth.pm test here? :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8367] How long is a hold waiting for pickup at a more granular level
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8367 --- Comment #314 from Tomás Cohen Arazi <tomascohen(a)gmail.com> --- Created attachment 158254 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=158254&action=e… Bug 8367: (QA follow-up) Fix broken tests 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 13325] Add logs for budgets and funds
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13325 --- Comment #19 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to mathieu saby from comment #18) > Well, in 22.11.05 it seems it works : > I activated acquisition's log and modified a fund (2880 euros -> 1880 euros) > > A new line appeared in the logs : > > - Date > - Librarian > - Module : Acquisition > - Action : Modify a fund > - Object : 21 > - Info : > {"budget_encumb_old":null,"budget_amount_new":"1880.00","budget_expend_old": > "0.000000","budget_expend_new":"0.00","budget_amount_old":"2880.000000", > "budget_encumb_new":"","budget_amount_change":-1000} > > > I also added a note, but unfortunately it was not logged. I didn't know that! thanks for reporting back :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 13325] Add logs for budgets and funds
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13325 --- Comment #18 from mathieu saby <mathsabypro(a)gmail.com> --- Well, in 22.11.05 it seems it works : I activated acquisition's log and modified a fund (2880 euros -> 1880 euros) A new line appeared in the logs : - Date - Librarian - Module : Acquisition - Action : Modify a fund - Object : 21 - Info : {"budget_encumb_old":null,"budget_amount_new":"1880.00","budget_expend_old":"0.000000","budget_expend_new":"0.00","budget_amount_old":"2880.000000","budget_encumb_new":"","budget_amount_change":-1000} I also added a note, but unfortunately it was not logged. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35228] REST API: Restricted staff users can see patron extended attributes (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35228 --- Comment #2 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- While researching, I looked at this condition in _handle_to_api_child: Koha::Exception->throw( "Asked to embed $curr but its return value doesn't implement to_api" ) if defined $next and blessed $child and !$child->can('to_api'); At first glance, it sounds good. But it actually does nothing. To_api is inherited from Koha::Object. So you 'can' do it. In this case you will get what you want. See below. At a higher level TO_JSON gets the details and to_api doesnt complain. use Modern::Perl; use Data::Dumper qw/Dumper/; use Koha::Patron::Attribute; my $child = Koha::Patron::Attribute->new({ code => 'TEST', attribute => '123' }); print Dumper( $child->can('to_api'), $child->to_api ); $VAR1 = sub { "DUMMY" }; $VAR2 = { 'type' => 'TEST', 'value' => '123' }; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 35228] REST API: Restricted staff users can see patron extended attributes (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35228 --- Comment #1 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Look at the /patrons test in bug 35227. Now first add a patron attribute like bank account number. Now test with header x-koha-embed=extended_attributes Now Henry also gets: "extended_attributes": [ { "extended_attribute_id": 589, "type": "ACCTNO", "value": "123456" } Why did he get those? We are protecting our embeds now, right? to_api goes for the extended_attributes relation to _handle_to_api_child which will call to_api again for Koha/Patron/Attribute.pm. This module only has its own to_api_mapping, no more specific security there. Sub is_accessible from Object just returns 1. We need more protection for patron attributes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 35227] REST API: Restricted staff users can see patron info (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35227 --- Comment #4 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Related thought: $patron->can_see_things_from feels too wide. We seem to need a context: which kind of things? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35227] REST API: Restricted staff users can see patron info (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35227 --- Comment #3 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- What is the best way to move forward here? Some options to think about: [1] Just removing label_creator, routing and order_manage from GET patrons is probably too simple. We may need a list of patron IDs and a name for some of these associated forms. [2] Could we go via public_patrons.yaml somehow on those staff forms ? It sounds weird to do so for a staff form. [3] Be strictier in can_see_things_from. Currently, the can = 1 for own branch allows this to happen. But how to refine that check exactly ? What would be the impact on other calls ? Note: The following line on the set permissions forms is misleading: "View patron infos from any libraries. If not set the logged in user could only access patron infos from its own library or group of libraries. (view_borrower_infos_from_any_libraries)" This is not true. If you gave acevedo only the abovelisted permissions, he is not EVEN able to access his OWN account info on staff (but he can on OPAC). He cannot see other accounts at all. [4] Given that can_see_things_from should still return 1 when not touching that sub, could we refine with something similar to unredact_list that we do now only when is_accessible returns false ? We feel the need here to provide some columns for staff but not immediately all columns, say staff_read_list ? Your feedback is welcome. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35227] REST API: Restricted staff users can see patron info (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35227 --- Comment #2 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Testing with user acevedo giving him label_creator and staff access. Fill few 'sensitive' fields like address, date_of_birth, email, mobile, staff_notes. Check results for /api/v1/patrons Acevedo received [partial output] for another patron (superlib): { "address": "Geheim adres", "cardnumber": "1", "category_id": "S", "check_previous_checkout": "inherit", "date_enrolled": "2023-11-02", "date_of_birth": "2000-11-01", "email": "secret(a)test.nl", "expiry_date": "2099-12-31", "firstname": "Koha", "lang": "default", "library_id": "MPL", "login_attempts": 0, "mobile": "p3", "patron_id": 1, "phone": "p1", "privacy": 1, "privacy_guarantor_checkouts": 0, "secondary_phone": "p2", "staff_notes": "circ_notes", "surname": "Admin", "updated_on": "2023-11-02T08:26:04+00:00", "userid": "koha.admin" }, How did the authorization go ? is_accessible => can_see_patron_infos => can_see_patrons_from => can_see_things_from + permission => 'borrowers', subpermission => 'view_borrower_infos_from_any_libraries', can_see_things_from RETURNS 1 for own branch ! In contrast to the POD line: Return true if the I<Koha::Patron> can perform some action on the given thing => The permission passed is only checked after if ( $self->branchcode eq $branchcode ) { $can = 1; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 35227] REST API: Restricted staff users can see patron info (not exposed via UI)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '23

02 Nov '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35227 --- Comment #1 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Current API authorizations in this context: /patrons: get: x-koha-authorization: permissions: - borrowers: "edit_borrowers" - tools: "label_creator" - serials: "routing" - acquisition: "order_manage" post: x-koha-authorization: permissions: borrowers: edit_borrowers "/patrons/{patron_id}": get: x-koha-authorization: permissions: borrowers: edit_borrowers put: x-koha-authorization: permissions: borrowers: "1" delete: x-koha-authorization: permissions: borrowers: delete_borrowers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0