10.0.10 (most likely problem is active since 10.0.8) empty float=error on save.

[Russ]

I had few fields since 2021, no problems on empty save ever, but now frontend prevents from saving, even with empty value, it's saying '$fieldName should be a valid float'
I am not sure I can post the video here (due to legal constraints), but I will post it to the portal.

[yuri]

Maybe some non-numeric value is set? E.g. empty string instead of null? Does it resolve if you set some field value, the save, then set it empty back and save.

[yuri]

Maybe caused by some 3rd party extension? Maybe some JavaScript error occurs before the Autonumeric library initializes the numeric fields. You can check: F12 > console.

I could not reproduce. There were no changes in the float and other number fields recently.

[Russ]

Maybe some non-numeric value is set? E.g. empty string instead of null? Does it resolve if you set some field value, the save, then set it empty back and save.

Thank you.

Looks like my local entityDef/Account.json had some wrong formatted values (for some reason, I didn't touch it manually).

Looks like a TS migration did this change.

Pre TS:
(this.params.options || []).forEach(...)

After TS:
(this.params.options ?? []).forEach(...)




My entity def:

custom/Espo/Custom/Resources/metadata/entityDefs/Account.json

Before:
146 "allowedZIPCodes": {
147 "type": "multiEnum",
148 "storeArrayValues": true,
149 "allowCustomOptions": true,
150 "options": false, ← Crash line, was ok for 4 years
151 "style": [],
152 "tooltip": true,
153 "isCustom": true
154 },


After:
146 "allowedZIPCodes": {
147 "type": "multiEnum",
148 "storeArrayValues": true,
149 "allowCustomOptions": true,
150 "options": [], <- Manual fix
151 "style": [],
152 "tooltip": true,
153 "isCustom": true
154 },



Thanks.