fieldErrors only references a single record
fieldErrors only references a single record
Hi
When you have errors in the data the Editor is sending to the server, the Editor will show the issue in the DataTables interface if you fill in the fieldErrors field in the returned JSON. You can have something like [{name: "start_date", status: "Please enter a date in the format yyyy-mm-dd"}]. This is great if you are editing a single record, but if you are editing multiple records it doesn't make sense. Suppose you modify multiple user records to have the same email address, but your system only allows unique email addresses. The first one would work, but the rest would fail, how is that fact going to be accurately returned to DataTables and show up in the dialog? Another example is that you set a date that is valid for some employees, but not for others, like 10 weeks of holidays which is great if they've been working long enough, but maybe not for new hires.
Peter
Answers
Hi
What is the correct UI behaviour for a multi-record update that partially fails? Should it deselect the rows that the update worked, and leave the failed ones selected and the dialog up (the error noted) so you can try again?
Peter
The Editor GUI only allows a single value to be submitted for the multiple rows (unless you submit the original values, which are assumed to be valid since they are already present), which is why the form validation only returns a status for a single field at the moment.
Unfortunately there is no way to return a different status for the different rows being edited using the default JSON schema since that generally isn't possible via the built in GUI. If that is something you need you'd need to extend the returns JSON with custom information.
Regards,
Allan
Hi
I'm reworking the errorFields into a more conventional REST response (within an 'errors' field that contains lots of details about each specific problem) , and building the errorFields data on the browser side from this. This is good in that is removes a DataTable-ism from the server API code.
I haven't decided how far I want to go with changing the UI behaviour based on the success/failure of multi-record updates.
Peter