When the patron fills in the form on the OPAC to edit their personal info it would be nice to highlight/mark the differences/changes. Currently we must manually compare every field in the email to their record to discover the changes they are requesting.
Changes made by patrons show up in all caps in the email. Maybe a note in the email telling the librarian that that's why the text is in all caps would be helpful. I have updated the manual for now.
Created attachment 5844 [details] [review] Proposed fix This patch eliminates all unchanged fields from the email on the assumption that the information is superfluous. I have also added a link to the patron edit screen which will be displayed if the staffClientBaseURL has been entered.
Created attachment 5845 [details] Screenshot of example email
Updating Version : This ENH will be for Koha 3.8
Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)
Patch applies clean, and works I leave it up to others to decide if its a good change.
Created attachment 6861 [details] [review] Fix for Bug 7006, highlight patron changes in email This patch eliminates all unchanged fields from the email on the assumption that the information is superfluous. I have also added a link to the patron edit screen which will be displayed if the staffClientBaseURL has been entered. Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
The described changes make sense to me. I had libraries complaining about the bad readability of the address change mail. Only showing changed information will make it easier. Another problem is that it's not a template in notices so can't be translated.
QA comment: small patch, works fine, perlcritic still OK after the patch. A good improvement could be to have the message translatable, but it was not before the patch, it's not after, that's another story...
(In reply to comment #9) > A good improvement could be to have the message translatable, but it was not > before the patch, it's not after, that's another story... See Bug 1153. We've been waiting for that for a while now.
There have been no further reports of problems so I am marking this bug resolved.