[Koha-bugs] [Bug 35310] Current renewals 'view' link doesnt work if renewals correspond to an item no longer checked out

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

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

--- Comment #21 from Victor Grousset/tuxayo <victor at tuxayo.net> ---
(In reply to Katrin Fischer from comment #18)
> I already suggested how to fake it:
> 
> (In reply to Katrin Fischer from comment #16)
> > I think in testing we need to make sure that there is no regression when
> > there are no entries in the table, but the renewals count on the checkout is
> > > 0 (maybe also needs a last renewed date if you are faking the data).
> 
> In issues:Ö increment the number in renewals_count and add a lastreneweddate.

I see, because the old data isn't migrated due to missing date, it's left here
and all places might need to account for two sources of renewals.

So how should it be accounted here? 
After more testing of the current patches:
- Item details page of a record doesn't show "Current renewals:" if there are
only legacy renewals.
- Item details page of a record and the modal only count stuff from
checkout_renewals. But patron circulation history counts them all. 

Back to the root, if I understand correctly: that transient state that happens
only when an instance just migrated causes to **either**
1. have (**temporary**) inconsistency in various places (if it affects circ
history, inconsistency it lasts a long as personal data retention delay of the
library)
2. add complexity in various places to account for two sources of renewal
numbers
3. have this complexity put in a single place in the model layer
4. actually migrate the old data in checkouts_renewals even if with no renewal
date.

Does the way old data was let in issues.renewals_count means that the current
strategy is to not bother with temporary inconsistency after migration? Then,
current patches here are in line with that.

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