5.1d BatchUploader does not request validation for required=false fields

[Blama]

Hi Isomorphic,

please see this SNAPSHOT_v10.1d_2015-10-14 BuilinDS based testcase.

See attached files plus DataSourceLoader row in the html file:

"builtinds/sc/DataSourceLoader?dataSource=supplyItem,animals,employees,employeesUpload,batchUpload")

1. Please upload the txt (rename to .csv) and see that the last three rows have errors.
2. Open the editor for field "Mentor" in row1, wait for the list to load, clear the server log (no error in row)
3. Select an entry in the client, leave the row
4. See that no validation takes place, even though an serverCustom validator is defined
5. Repeat steps 2-4 for row2 with the same result (no validation) (no error in row)
6. Repeat steps 2-4 for row3 with the same result (no validation) (error in edited column)
7. Repeat steps 2-4 for one of the rows 4-5. Here server validation is done (error in different column)

Then try the same for field "Manager". Here the validation is done for all rows.
Root cause seems to be that the "Mentor"-field is required=false.

I'd think that the validation should be done always (for a server-validator) independent of this the field being required=true or the row having other errors.

Best regards
Blama

[Blama]

Perhaps this is more of a ListGrid issue than a BatchUploader issue?

[Isomorphic]

We've had a developer look at this issue and they're not reproducing what you're describing.

According to our tests, when we load the data file, There are errors in two rows, 3 and 5, and when we follow the steps to reproduce the issue, we don't see validation errors on either the "Mentor" field or the "Manager" field.

Actually, as the TrueValidator.condition method always returns true this would seem to be expected - by returning true it is allowing validation to pass.

Can you verify that your test case is complete? Assuming so, we must be missing something in the steps to reproduce or similar - can you clarify?

Thanks

[Blama]

Hi Isomorphic,

I retested with the very same code and SNAPSHOT_v10.1d_2015-10-22/PowerEdition Deployment. The perceived error is still there, but the description was not 100% correct. There are only errors in row 3 and 5, like you said.

The TrueValidator does what it is expected - log a message and return true. The log message shows that it is actually called (it is only about the calling of validation, not the result, which is correct).

The problem description can be made more clear. Here again with more details:


Start the sample.

1. Change a value Mentor in rows 1,2,4 - no validation is called.
2. Change a value Mentor in rows 3,5 - validation is called for the whole row (3x true validator, hasRelatedRecord, etc) (this is because the rows have errors from my observations)
   1. If you changed row 3 from "TYPO" to a correct value, the row has no more error and a 2nd and 3rd change won't call validation
   2. If you changed row 5 from one correct value to another, validation will occur every time, even if you fix the error in column "ReportsTo"

Now close the SmartGWT upload window and click the recreate button.

1. Change the "Name" column in any row. Validation is called for the whole row for every change.

Salary and Mentor columns behave exactly the same.



Now close the SmartGWT upload window and click the recreate button.

1. Change the "Gender" column in row 1,2,4. No Validation is called
2. Change the "Gender" column in row 3. No Validation is called, but the Mentor error is gone and the value shown in blue.
3. Change the "Gender" column in row 5. Validation is called.

Title column behaves exactly the same.

• In my opinion the behavior for Name, Salary and Mentor is correct - server validation should occur always for every change for the whole row if at least one column has a validator that can only be run on the server (meaning a serverObject or velocityExpression validator which can use values from other columns in their definition. This does not apply to hasRelatedRecords and isUnique validators. Here the validation definitely has to be triggered for changes in this field, but not for changes in other fields as well.)
• Behavior for Gender and Title is clearly a bug. I don't know if you need to fix this, because it would not occur if the whole row is sent to server validation.
• Behavior for Mentor is just strange and also clearly a bug. The only difference to ReportsTo is that it does not have required="true".

Best regards
Blama

[Blama]

Hi Isomorphic,

can you reproduce with the revised testcase?
W.r.t your answer here you might disagree with bullet-point #1, but then it is unclear why the TrueValidator is already called three times for the mentioned field-change. #2 and #3 are bugs IMHO.

Best regards
Blama

[Isomorphic]

We got to the bottom of the problem with the server side validator not being called when the field was not marked as required. We are reproducing it and have the bones of a fix in place. We'll follow up when we have this checked in.

We'll make sure we consider your comments from post #4 when getting this in.

Thanks
Isomorphic Software

[Isomorphic]

We've made a change to solve this issue. Please try the next nightly build, dated November 03.

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

in case you did not notice: There is no 5.1d (or 5.0p) build available since 2015-10-31.

Best regards
Blama

[Blama]

Hi Isomorphic,

I noticed that when validation does happen for client side changes is still very strange and not consistent.
I'm using the same testcase as in #1, now with v10.1p_2016-11-08.

Steps to reproduce:

1. Open the Developer Console RPC Tab
2. Upload the CSV file (5 rows, row#1 "Anna Sun", row#2 "Mike Sun")
3. Change gender of Anna Sun to "Male"
4. Validation request is sent
5. Change gender of Mike Sun to "Female"
6. No validation request is sent. I'd expect one here as well.

Video:



This is an important one for me, as something similar is currently happening in my application.

Best regards
Blama

[Isomorphic]

This is fixed now and will be available for download in nightly builds since Dec 6 (tomorrow).

Inconsistent behavior is fixed in a way that none of showcased record changes will trigger a validation call, cause Gender field does not have server validators declared. Alternatively, if validation is intended in this case, you may declare dummy server validator on Gender field, which will enable validation on Gender field change.