Bug 11220

Summary: Patron edit process doesn't remember restriction selections
Product: Koha Reporter: Owen Leonard <oleonard>
Component: PatronsAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: barton, gmcharlt, jonathan.druart, kyle.m.hall
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22805
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Owen Leonard 2013-11-08 14:51:24 UTC 
If you are editing a patron who has an existing restriction or you are adding a manual restriction, the form doesn't remember your selections if the page is redisplayed after an error.

The problem cannot be demonstrated by a validation error which is caught by the client-side validation. It has to be a server-side validation error in order to trigger the full refresh of the page after error. In my case the error was triggered because the existing patron's dateofbirth was '0000-00-00' in the database and Koha returned an error message because of this.

To reproduce using a patron record which has no restrictions:

1. Start with a patron record which will trigger a server-side
   error message.
2. Add a manual restriction in the "Patron restrictions" section of
   the edit form.
3. Submit your changes.
4. After the page refreshes the form will be redisplayed with an error
   message at the top. Whatever data you entered for the manual
   restriction will be gone.

To reproduce using a patron record which has restrictions:

1. Start with a patron record which will trigger a server-side
   error message.
2. Check the box next to the existing restriction you want to remove.
3. Submit your changes.
4. After the page refreshes the form will be redisplayed with an error
   message at the top. The checkbox you checked will be empty.
Comment 1 Jonathan Druart 2015-04-24 08:37:27 UTC 
Still valid.
Comment 2 Barton Chittenden 2019-03-28 19:44:27 UTC 
This is true for other patron fields, e.g. changes to Alternate Address are lost as well.
Comment 3 Jonathan Druart 2019-05-04 14:00:45 UTC 
On bug 22805 I am suggesting to improve the incorrect dates handling client-side, to avoid server-side explosion.
I know I am cheating here, but which other (known) errors could cause a server-side error?