Bug 25995

Created attachment 107411 [details] [review]
Bug 25995: Log RENEWAL when "extend due dates" tool is used

RENEWAL logs are created when an issue is renewed from the circulation
module. We should log as well when the "extend due dates" tool is used
to renew issues.

Test plan:
Turn on RenewalLog
Create an issue
Renew it using the "extend due dates"
Confirm that the log has been created

A change with the extend due dates tool isn't strictly a renewal and doesn't count as one when calculating renewals allowed. Seems like it could get confusing to log it as such. If we don't want to go as far as introducing a new type of action, I think it might make more sense to record these as "Modify."

There is a "modify item" log that is created already.

I think Action modify + module circulation would be a good fit. We are not changing the item, but an issue - that would make it clear and reuse existing values.

I saw that this change to due date is currently recorded in the cataloging log as a modification to the item, yes. That's helpful at the moment, while we're not otherwise logging this. But we have a lot of libraries that don't use the cataloging log due to its size.

We pointedly removed all other circ-related item changes from the cataloging log. Should this change be excluded from the cataloging log, too?

Created attachment 107476 [details] [review]
Bug 25995: Remove existing CATALOGUING/MODIFY log

We had a log when the item was modified. We previously removed such
cataloguing log from circulation (bug 18816)

Is this patch correct? I am not sure I understand Katrin's comment (comment #4).

I was suggesting to log it as MODIFY instead of RENEWAL within the circulation logs, so we can tell them apart. As Andrew points out it's not a regular renewal but a forced change of date.

a new "BATCH_RENEWAL" then?

I'd prefer to avoid the term "renewal" entirely, since this is not a renewal and doesn't count against the patron's count of renewals allowed. It's a minor distinction, but one I expect could be a source of confusion for users.

circulation+modify then?

(In reply to Jonathan Druart from comment #11)
> circulation+modify then?

Seems like the best option to me!

Created attachment 107499 [details] [review]
Bug 25995: Log CIRCULATION+MODIFYwhen "extend due dates" tool is used

RENEWAL logs are created when an issue is renewed from the circulation
module. We should log as well when the "extend due dates" tool is used
to renew issues. As they are not proper renewals, CIRCULATION+MODIFY
will be used.

Test plan:
Turn on RenewalLog
Create an issue
Renew it using the "extend due dates"
Confirm that the log has been created

Created attachment 107500 [details] [review]
Bug 25995: Remove existing CATALOGUING/MODIFY log

We had a log when the item was modified. We previously removed such
cataloguing log from circulation (bug 18816)

Patches updated, a CIRCULATION+MODIFY log is now created if RenewalLog is set.
Not sure it's what we want however.

The more I think about this, I'd like to see this logged regardless of the renewal log. Because this tool changes due dates in a manner wholly outside the circ rules, we've seen a lot of confusion when its use isn't well documented. As such, I think we should always log it.

Hm, I think as the logs contain 'personal data', we should maintain the ability to decide not to keep logs for the libraries. But I think RenwalLog might not be the right one. What about using Issuelog instead, which matches our change to "CIRCULATION" and add the case to the pref description?

What about a new "tools" module for logs?

Hm, that could work. Andrew, what do you think?

Good point about being able to opt out of logging personal data. I think a new Tools Log module and corresponding syspref is reasonable.
If we're establishing a new module, what data do we write into the log? How about object = issue_id, info = new due date?
Recording the issue_id rather the borrowernumber breaks the tie back to the patron, if they're anonymizing their reading history.