Automatic renewal RFC
From Koha Wiki
Koha > Technical > Development > RFCs
Koha > Technical > Development > RFCs > Koha components for RFCs > Library System Modules RFCs > Circulation RFCs
Automatic renewal RFC
|Sponsored by:||Hochschule für Gesundheit (hsg), Germany|
|Developed by:||Holger Meißner|
|Bug number:||Bug 11577|
|Work in progress repository:||No URL given.|
|Description:||This is a working document and will be expanded as new ideas, progress and problems occur.|
The feature has been pushed. So this page is now obsolete. Thanks everyone!
Our library wants a new “automatic renewal” feature, that enables some patrons to borrow items for a long time, without having to renew manually. So for certain combinations of patron category and item type, renewals will be done by a cronjob. Automatic renewal stops when a hold is placed or when the given number of allowed renewals is exceeded.
At least two new parameters are needed. They might be called something like:
When to renew. X days or hours before due date. This is already introduced by bug 7413 where this new parameter is used to restrict manual renewals. CanBookBeRenewed returns a new error "too_soon" if the current time + X hours|days is less then the due date. The cronjob can use this as well and simply renew every loan where auto_renewal is set and no renewal error occurs. Auto_renewal could require a value for norenewalbefore or it could renew a loan only if it's already overdue.
I plan to modify both the "Circulation and fine rules" table and the checkout page. Feel free to propose different ideas.
Circulation and fine rules
Add a switch for auto_renewal. I suppose a drop-down is more verbose and matches the table better than a checkbox? Or should input fields for yes/no always be checkboxes? It could be placed before or after the input field for norenewalbefore.
I noticed that bug 9129 uses a checkbox. So I guess, I should use one too, for consistency.
- Personally, I would fail QA on a patch that reduced consistency, so would stick with the dropdown yes/no. However, I think your right that really yes/no options should be checkboxes, but I think that would have to be a followup patch that changed all option within that table at least to be consistent. Owen Leonard is your man for consistent styling advice. MRenvoize 04:31, 7 March 2014 (EST)
Add a checkbox, so automatic renewals can be done for single loans as well.
- Should the display of the 'automatic renewal' option be permissions based.. i.e. can all staff issue something with the auto renew option should the time live up to all the constraints.. or is it still something that only certain library staff should be able to do? MRenvoize 04:33, 7 March 2014 (EST)
- add auto_renew to issuingrules
- add auto_renew to issues
- add norenewalbefore to issuingrules
Since the circulation and fine rules are already cluttered and some libraries might not want to use automatic renewal at all, maybe the feature should be enabled/disabled by a new system preference. The syspref would show/hide the feature in the GUI. So no one could use it accidentally. On the other hand, this might be confusing. If the syspref is to be used, what should be the default value?
Should there be a special notice for automatic renewals? Or is it sufficient when the standard renewal notice is sent (or isn't sent, depending on preferences)? Some libraries might want to differentiate. Maybe do this as a follow-up, rather than include it right away?
Should patrons be able to switch automatic renewal on/off in the OPAC? There would be two possibilties:
- Only staff decides which loans are automatically renewed (issuing rules, or checkbox for single loans), but patrons may opt to disable it.
- Every patron is allowed to enable automatic renewal, but it's off by default.
Maybe do this as a follow-up, rather than include it right away?
Files to be edited
Are there any other files, that I might have to look into?
This would be a new script.
Potential problems and followups
- Prevent conflicts with manual renewals: Depending on when the cronjob runs, a patron might be able to renew manually, loosing a bit of time.
- Messaging preferences: Depending on those, a patron might repeatedly get an advance notice, before the cronjob renews.