https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42418 --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #11)
(In reply to Katrin Fischer from comment #10)
Can you explain a bit how this will affect old_issues or if there are plans for old_issues down the road?
Another solution could have been to add additional columns to old issues as that represents a checkin currently. I guess you had reasons not to go this route, but am a bit worried about the duplicated data.
I always think of `old_issues` as the `issues` table with information about a special status of the checkout: returned (which is inferred from a return date being set). With that in mind my only plan is to merge those tables in the mid (?) term.
The other option would be to have a checkins and a checkouts table long term.
But -regardless of what we do with those tables- this development highlights that the checkin action can (or not) trigger some status change for a checkout, and many more things. All of those nicely handled and tested here :-).
I was not saying this is not a solid development, I just wonder how it will fit with the existing structures.
Taking accountlines as an example, I will propose we ditch the old_issues link and replace with a checkin link. That way we actually gain tracking possibilities for (say) refunding lost fines even when there might not be a linked checkout, and things like that. The link to old checkouts could be reconstructed through the checkin link.
"ditching" will require some good thinking as we will need to retain the old link for old data or move the data into checkins first. And if we move that link, that means for data migrations we will need to fill one more table. Right now it's already a bit confusing as some reports use statistics, others use old_issues and now we will have checkins in the future as well. All recording the checkin. -- You are receiving this mail because: You are watching all bug changes.