https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27034 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #115796|0 |1 is obsolete| | --- Comment #11 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 115805 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=115805&action=edit Bug 27034: Do not use path parameters on building the query This patch simply removes the use of path parameters on building the query in $c->objects->search. The sample usage in the original tests considers a specific use case in which the 'nested' resultset has the path param in its attributes: GET /patrons/:patron_id/holds In this case, $c->objects->search would be passed a Koha::Holds resultset into which it would build a query. As the patron_id param can be mapped into a Koha::Hold attribute, this works. We don't actually use this approach in code. What we do is searching for the patron, and properly return a 404 if the patron doesn't exist [1]. If it exists, we actually call $patron->holds to get the related resultset, so there's no gain in having the path param on the query afterwards. That said, if we wanted to build: GET /holds/:hold_id/pickup_locations as the latter is a calculated value, from a resultset that doesn't actually include a (mapped to some attribute) hold_id attribute, there's no way to use it if it will automatically add the hold_id to the pickup_locations resultset. It will give errors about hold_id not being an attribute of Koha::Library (Branches.pm actually). So this patch removes the automatic use of path parameters in $c->objects->search. We can extract them in the controller and add them to the passed resultset if required. But this patch removes a constraint we have for building routes controllers right now. [1] If we didn't return the 404, and we just passed a fresh Koha::Holds resultset to be feeded with the patron_id, we would always return an empty array in cases where the patron doesn't exist. This would be misleading, but I'm open to discuss it. Design-wise. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes.