[Koha-bugs] [Bug 23838] Add ability to view item renew history

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

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

--- Comment #38 from Andrew Isherwood <andrew.isherwood at ptfs-europe.com> ---
(In reply to Katrin Fischer from comment #36)

1 & 2)

> There is a strong pattern in the patches, file names, the API path of
> patron-renewals. Tbh, I wonder if this is not misleading. I'd expect
> something to do with membership renewals for patrons here. I wonder if we
> should add the checkout aspect here.

I agree it could be misleading. I think your suggestion of an alternative API
route makes sense. Looking at the spec I created, I had the patron_id as an
optional parameter, though I'm not sure that makes sense, I can't think of any
case where you'd want to retrieve *all* a patron's renewals. I'm going to
retain the "embed" optional parameter as I do think this is useful. So, to
summarise, I'll change the route to:

GET
/patrons/{patron_id}/checkouts/{checkout_id}/renewals(?embed=patron,renewed_by)

3) Is there a strong reason to favor action_logs over statistics here?

Statistics doesn't store the identity of who performed the renewal, which was a
key requirement for our customer. There is no reliable way of obtaining that
information, hence the use of action_logs which, I agree, are not an ideal
solution for the reasons you mention. I'm not sure how reasonable it would be
to add a, perhaps, "operator" column to statistics, which would enable us to
record the renewing staff member. I'm not really familiar with the purpose of
the statistics table, but it looks pretty multipurpose, so adding a column of
this nature may not be appropriate.

4)

> But after 4) I have the same information show on both entries.
> 3 renewals = 2 renewals logged on 2020-05-14
> 1 renewal = 2 renwals logged on 2020-05-15

> This leads me to believe that this can't deal with multiple checkouts of the same item.

This seems to be a bug. Currently the API call just gets all renewals for a
specific patron / item combination, hence the result you're seeing. We could
pass the appropriate issue ID to the modal, which would enable it to get just
the renewals for that specific issue. However, the issue ID is not recorded in
entries made in the action_logs, so we'd have to add that. Or, assuming, we
decide to stop using action_logs, it would need to be added whereever we record
it.

5) OK, thanks, I'll fix those.

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