[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

Katrin Fischer <katrin.fischer at bsz-bw.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |Failed QA

--- Comment #36 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
I started to test these and to code review and there are some points I have
been wondering:

1) Patron (membership) renewal vs. checkouts renewal

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. 


2) REST API

This adds a new route to our REST API:
/patrons/{patron_id}/renewals

But it doesn't appear to have an RFC and has not been voted on yet. If you
could write something up, we could maybe fast track at in the meeting this
Wednesday:
https://wiki.koha-community.org/wiki/REST_api_RFCs

Because of one, maybe this would be better:

GET /patrons/{patron_id}/checkouts/{checkout_id}/renewals


3) Database structure / tables

So far we have pulled statistics related data form issues, old_issues and
statistics, which also logs renewals. I think the action_logs was mostly used
for the log viewer (hope I didn't miss something). 

So deleting the action_logs, didn't have much consequence. I am worried, that
libraries haven't kept the data in the action_logs so this won't work as
expected. Since a long time, we have an option in the cleanup_database.pl
script to delete log entries older than x days. 

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

In 20.05 we will also have an option for old_issues and statistics. Tbh - I
would not recommend a library using either of these as they delete and you lose
valueable data about the use of your collection. It will kill your reading
histories, I'd always prefer anonymizing, but we don't have that option yet in
the cleanup scripts. I think some strong warning notes about consequences
should be the least we do.

I know our database situation here is less than ideal. :( If I am correct we
are missing the issue_id in both tables?

4) Wrong data showing

The scenario (very likely in a lot of our libraries with course books
especially):

1) Patron A checks out the book
2) Renewals take place until no more renewals are allowed
3) Patron A returns the book and checks it out again immediately
4) More renewals take place

In my testing after 2) I had 

3 renewals showing in the table, when I click on Details 2 showed.
This was due to me turning on RenewalLog too late (so ok)

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.


5) QA script

Only 2 very minor problems, probably caused by clean-up since these patches
were written:

 FAIL   t/db_dependent/api/v1/patrons_renewals.t
   OK     critic
   FAIL   forbidden patterns
                forbidden pattern: Incorrect license statement (using postal
address), may be a false positive if the file is coming from outside Koha (bug
24545). (line 16)

 FAIL   Koha/REST/V1/Patrons/Renewals.pm
   OK     critic
   FAIL   forbidden patterns
                forbidden pattern: Incorrect license statement (using postal
address), may be a false positive if the file is coming from outside Koha (bug
24545). (line 16)


Failing for 4) and 5) (would have fixed 5) in QA, but needs more work). 
1) should be resolved as well to our agreed workflow. 
2) and 3) I hope to discuss, maybe get more opinions on.

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