At the moment you can submit the personal details form without changes, which will create an "empty" address change request in the staff interface. It would be nice if we checked for changes and didn't create these empty requests.
We just got another report of this, so giving this another 'bump'.
+1 We've been getting lots of odd blanks on the pending request modifications lately as well.
Created attachment 166022 [details] [review] Bug 35929: Don't record a change for empty fields submitted in patron form This is reminiscent of bug 36159 - when a field is submitted as empty, and null in the DB we need to reject this as a change. I tried to copy the logic from that bug, as well as deleting submitted changes for hidden fields (from html manipulation) This should be tested extensively. One note: If you submit a valid change request, then submit a second with no change the second will be ignored, but the first will remain. i.e. if you change your name from 'Nick' to 'Nack' - then realize your typo you cannot submit a new request to change it back untl the initial request is cleared To test: 1 - Play with PatronSelfModificationBorrowerUnwantedField and PatronSelfModificationMandatory field to have some fields set 2 - Add a patron attribute, or several, that are editable in the OPAC 3 - Try submitting a form with no changes, note a modification requets is submitted 4 - Approve the request 5 - Apply patch, restart all 6 - Try submitted a blank request, you are notified there were no changes 7 - Try to force an unwanted field via html modification 8 - No changes reported 9 - Confirm attributes changes are successful 10 - After a successful request, try submitting a blank request 11 - Note no changes are recorded, but the initial request is still active
Created attachment 166023 [details] [review] Bug 35929: Don't record a change for empty fields submitted in patron form This is reminiscent of bug 36159 - when a field is submitted as empty, and null in the DB we need to reject this as a change. I tried to copy the logic from that bug, as well as deleting submitted changes for hidden fields (from html manipulation) This should be tested extensively. One note: If you submit a valid change request, then submit a second with no change the second will be ignored, but the first will remain. i.e. if you change your name from 'Nick' to 'Nack' - then realize your typo you cannot submit a new request to change it back untl the initial request is cleared To test: 1 - Play with PatronSelfModificationBorrowerUnwantedField and PatronSelfModificationMandatory field to have some fields set 2 - Add a patron attribute, or several, that are editable in the OPAC 3 - Try submitting a form with no changes, note a modification requets is submitted 4 - Approve the request 5 - Apply patch, restart all 6 - Try submitted a blank request, you are notified there were no changes 7 - Try to force an unwanted field via html modification 8 - No changes reported 9 - Confirm attributes changes are successful 10 - After a successful request, try submitting a blank request 11 - Note no changes are recorded, but the initial request is still active Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 167006 [details] [review] Bug 35929: Don't record a change for empty fields submitted in patron form This is reminiscent of bug 36159 - when a field is submitted as empty, and null in the DB we need to reject this as a change. I tried to copy the logic from that bug, as well as deleting submitted changes for hidden fields (from html manipulation) This should be tested extensively. One note: If you submit a valid change request, then submit a second with no change the second will be ignored, but the first will remain. i.e. if you change your name from 'Nick' to 'Nack' - then realize your typo you cannot submit a new request to change it back untl the initial request is cleared To test: 1 - Play with PatronSelfModificationBorrowerUnwantedField and PatronSelfModificationMandatory field to have some fields set 2 - Add a patron attribute, or several, that are editable in the OPAC 3 - Try submitting a form with no changes, note a modification requets is submitted 4 - Approve the request 5 - Apply patch, restart all 6 - Try submitted a blank request, you are notified there were no changes 7 - Try to force an unwanted field via html modification 8 - No changes reported 9 - Confirm attributes changes are successful 10 - After a successful request, try submitting a blank request 11 - Note no changes are recorded, but the initial request is still active Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 167007 [details] [review] Bug 35929: Remove extra parenthesis and make it more readable Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Thanks for that one!
Pushed for 24.05! Well done everyone, thank you!
Pushed to 23.11.x for 23.11.06
Backported to 23.05.x for upcoming 23.05.12