[Koha-bugs] [Bug 35353] Add API endpoint to fetch patron's previous holds

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Fri Dec 15 22:17:27 CET 2023


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

Tomás Cohen Arazi <tomascohen at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.koha-community
                   |                            |.org/bugzilla3/show_bug.cgi
                   |                            |?id=20936
             Status|Signed Off                  |In Discussion

--- Comment #4 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
On the original implementation for bug 20936, we implemented this on the API...
it is sad how it become a rabbit hole and we dropped that dev entirely! (we
were requested to 'first solve how Koha handles timezones in dates on the
API'!).

Anyway, in that context I remembered the discussion...

As opposed to what happens with biblios, items and patrons, which when deleted
are really just put in a vault until a maintenance tool decides to clear them
for good, checkouts, holds, etc are transactions which change their statuses,
and that status can just be 'finished' or 'completed'.

As 'reserves' and 'old_reserves' are not yet merged (maybe this cycle?) we
don't have a clean way to implement it. But on bug 20936 we overcome this by
adding an 'old=1' query parameter on the current */holds endpoint. The
advantage is that, if the tables are merged, we can just translate old=1 into
$rs->filter_by_complete or similar, keeping the behavior.

TL;DR

1. The ideal would be to implement this on top of bug 25260, with 'completed'
being just another (set of?) status value which we can filter on. Adding a
special query parameter to make it return completed holds seems fairly
straight-forward.
2. Implementing this in the spirit of bug 20936 (see [1]) could work without
needing bug 25260, and keeping forward compatibility, behavior and query
parameters wise.

I feel that's the way to go.

My 2 cents.

[1] https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=100473

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


More information about the Koha-bugs mailing list