Description
Marcel de Rooy
2019-02-05 13:31:59 UTC
Created attachment 96424 [details] [review] Bug 22273: Replace typo opan by opac in POD Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 96425 [details] [review] Bug 22273: Database revision for table article_requests Column created_on should not be updated. It is filled once by the store method of Koha::ArticleRequest. Column updated_on should be a timestamp, updated by the database. Note: Although higher versions of MySQL and MariaDB support two timestamps (NOT NULL) in one table, I kept on the safe side by allowing NULL on the created_on column. @RM: Don't forget to run DBIx update. Test plan: Run new install or upgrade. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 96426 [details] [review] Bug 22273: Modify Koha::ArticleRequest->store to fill created_on For a new record, store should fill created_on. The database will always update the timestamp updated_on. Since open also calls SUPER::store, we do not need to call it twice. Test plan: [1] Run t/db_dependent/ArticleRequests.t [2] In the interface, add two article requests. Change the status of one to PROCESSING. Check created_on and updated_on in the article_requests table. The changed request should have updated_on > created_on. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Created attachment 99787 [details] [review] Bug 22273: Replace typo opan by opac in POD Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Created attachment 99788 [details] [review] Bug 22273: Database revision for table article_requests Column created_on should not be updated. It is filled once by the store method of Koha::ArticleRequest. Column updated_on should be a timestamp, updated by the database. Note: Although higher versions of MySQL and MariaDB support two timestamps (NOT NULL) in one table, I kept on the safe side by allowing NULL on the created_on column. @RM: Don't forget to run DBIx update. Test plan: Run new install or upgrade. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Tested running update. Created attachment 99789 [details] [review] Bug 22273: Modify Koha::ArticleRequest->store to fill created_on For a new record, store should fill created_on. The database will always update the timestamp updated_on. Since open also calls SUPER::store, we do not need to call it twice. Test plan: [1] Run t/db_dependent/ArticleRequests.t [2] In the interface, add two article requests. Change the status of one to PROCESSING. Check created_on and updated_on in the article_requests table. The changed request should have updated_on > created_on. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> [1] Tests pass ok 12 - New article request has created_on date set ok 13 - New article request has updated_on date set [2] Work as described. No errors This works well. Should we try and fix the updated_on with the created_on on update? Created attachment 99836 [details] [review] Bug 22273: Replace typo opan by opac in POD Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 99837 [details] [review] Bug 22273: Database revision for table article_requests Column created_on should not be updated. It is filled once by the store method of Koha::ArticleRequest. Column updated_on should be a timestamp, updated by the database. Note: Although higher versions of MySQL and MariaDB support two timestamps (NOT NULL) in one table, I kept on the safe side by allowing NULL on the created_on column. @RM: Don't forget to run DBIx update. Test plan: Run new install or upgrade. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Tested running update. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Created attachment 99838 [details] [review] Bug 22273: Modify Koha::ArticleRequest->store to fill created_on For a new record, store should fill created_on. The database will always update the timestamp updated_on. Since open also calls SUPER::store, we do not need to call it twice. Test plan: [1] Run t/db_dependent/ArticleRequests.t [2] In the interface, add two article requests. Change the status of one to PROCESSING. Check created_on and updated_on in the article_requests table. The changed request should have updated_on > created_on. Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> [1] Tests pass ok 12 - New article request has created_on date set ok 13 - New article request has updated_on date set [2] Work as described. No errors Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Thanks Bernardo and Katrin (In reply to Katrin Fischer from comment #7) > This works well. Should we try and fix the updated_on with the created_on on > update? Did not think that it was so important for article requests to do so. Normally I expect these dates to be quite close to each other. Nice work everyone! Pushed to master for 20.05 We got quite a few reports for libraries that use article requests - was thinking more along these lines :) Pushed to 19.11.x branch for 19.11.05 |