|
Description
Nick Clemens (kidclamp)
2021-10-07 14:33:24 UTC
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! |