Bug 26498 added the syspref 'DefaultHoldExpirationDate' It is implemented in Koha::Hold->store by saving a DateTime object into the expirationdate This works fine, but the logs are flooded by this object
Created attachment 125889 [details] [review] Bug 29192: Set expirationdate as string when storing Hold To test: 1 - Enable HoldsLog in system preferences 2 - Set system preferences: DefaultHoldExpirationDate: Set DefaultHoldExpirationdatePeriod: 5 DefaultHoldExpirationdateUnitOfTime: days 3 - Create a hold for a patron 4 - Note the expiration date is set 5 - Check the action logs - SELECT * FROM action_logs 6 - Note that there is a lot of data, this is from DateTime object in expirationdate 7 - Apply patch 8 - Restart all 9 - Place another hold 10 - Confirm expiration date set correctly 11 - View the logs 12 - Entry for new hold contains only the date, no extra data
Created attachment 125891 [details] [review] Bug 29192: Set expirationdate as string when storing Hold To test: 1 - Enable HoldsLog in system preferences 2 - Set system preferences: DefaultHoldExpirationDate: Set DefaultHoldExpirationdatePeriod: 5 DefaultHoldExpirationdateUnitOfTime: days 3 - Create a hold for a patron 4 - Note the expiration date is set 5 - Check the action logs - SELECT * FROM action_logs 6 - Note that there is a lot of data, this is from DateTime object in expirationdate 7 - Apply patch 8 - Restart all 9 - Place another hold 10 - Confirm expiration date set correctly 11 - View the logs 12 - Entry for new hold contains only the date, no extra data Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Created attachment 125898 [details] [review] Bug 29192: Discard changes before logging a newly created hold When logging a newly create hold it can have a dt object in the expiration date field Per bug 28700 this does not get unblessed We add an explicit call to discard changes to avoid logging a blessed datetime To test: 1 - Enable HoldsLog in system preferences 2 - Set system preferences: DefaultHoldExpirationDate: Set DefaultHoldExpirationdatePeriod: 5 DefaultHoldExpirationdateUnitOfTime: days 3 - Create a hold for a patron 4 - Note the expiration date is set 5 - Check the action logs - SELECT * FROM action_logs 6 - Note that there is a lot of data, this is from DateTime object in expirationdate 7 - Apply patch 8 - Restart all 9 - Place another hold 10 - Confirm expiration date set correctly 11 - View the logs 12 - Entry for new hold contains only the date, no extra data
Created attachment 125966 [details] [review] Bug 29192: Discard changes before logging a newly created hold When logging a newly create hold it can have a dt object in the expiration date field Per bug 28700 this does not get unblessed We add an explicit call to discard changes to avoid logging a blessed datetime To test: 1 - Enable HoldsLog in system preferences 2 - Set system preferences: DefaultHoldExpirationDate: Set DefaultHoldExpirationdatePeriod: 5 DefaultHoldExpirationdateUnitOfTime: days 3 - Create a hold for a patron 4 - Note the expiration date is set 5 - Check the action logs - SELECT * FROM action_logs 6 - Note that there is a lot of data, this is from DateTime object in expirationdate 7 - Apply patch 8 - Restart all 9 - Place another hold 10 - Confirm expiration date set correctly 11 - View the logs 12 - Entry for new hold contains only the date, no extra data Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Simple fix, no side effects, passes qa scripts. Going straight for PQA
Missing test coverage.
I was going to write the tests when I remembered bug 28700. Please help there!
*** This bug has been marked as a duplicate of bug 28700 ***