[Koha-bugs] [Bug 27034] New: $c->objects->search shouldn't use path parameters

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27034

            Bug ID: 27034
           Summary: $c->objects->search shouldn't use path parameters
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: REST API
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: tomascohen at gmail.com

The objects.search Mojolicious helper incorrectly adds path parameters to the
query for filtering.
This works, trivially for plat routes like:

GET /patrons/:patron_id

or for routes that really have links like (fictional example):

GET /patrons/:patron_id/holds

In the latter, we already know there's a link borrowers<->reserves so searching
holds and filtering by the borrowernumber will work.

About this there are two things to consider:

- That's not how we are coding, we are actually picking the patron_id manually
and using object methods to access the resultset:

    my $patron = Koha::Patrons->find( $c->validation->param('patron_id') );
    ...
    my $holds_rs = $patron->holds;
    my $holds    = $c->objects->search({ resultset => $holds_rs });

- If we have more tricky examples like:

    GET /holds/:hold_id/pickup_locations

it is obvious that hold_id doesn't make any sense for Koha::Libraries, so
filtering on it actually causes an exception.

One option is to manually remove the problematic path parameters in the
controller:

    my $hold_id = $c->validation->param('hold_id');
    my $hold    = Koha::Holds->find( $hold_id );

    delete $c->validation->output->{'hold_id'};

    my $pickup_locations_rs = $hold->pickup_locations;
    my $pickup_locations = $c->objects->search( $pickup_locations_rs );

My feeling is that we should be following the current pattern, and not really
use the path parameters in objects.search. If we later need some handling in
the generic objects->search helper, we can reintroduce it, but we need a real
use case, which cannot be found in the codebase yet. It all points towards not
needing them there, and just getting in the middle with no gain (just the
opposite).

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.