Read Only fields validation issue.

[partomas]

Hello, after upgrade to 7.2.4 we figured out an issue with a Read-Only fields.

We used them as Layout Read Only limitation for users layout, but Hook, after save and other system scripts, formulas could update the values (like described in attachment). But after upgrade to 7.2 system started ignore any other updates in backend because of read-only.
We understand the sense of Read-Only fields, but we need to have "User Interface Read-Only" fields that we could calculate and enter different values, just users or portal users couldn't edit them in UI.
Now we taken off Read-only limitation to get working system back, but it's danger from business perspective. How anyone solve the issue?

[partomas]

yuri is there are any fast fix or workaround to have "User Interface Read-Only" field limitation?

[yuri]

I think you missed something. There must be some other customization in frontend. What you described, it should work with a read-only field.

[partomas]

One more example in quote status:

Conditions making field read-only
Edit
(
Status ∈ (RFP (Request For Price) , RFP Approved , Approved , Rejected , Canceled )
AND
Is admin ≠ 1
AND
Invoice Number ≠ ∅
)
make not editable status field if we getting Error by background workflows or scripts and can't change status or add addition "error" information based on aftersave scripts result.

[yuri]

I don't get this.

There was no any change with dynamic logic.

[partomas]

yuri in dynamic logic there are no changes, but because of it there issues with aftersave and other scripts don't work well.

[telecastg]

Unfortunately at present, the only way to solve these "validation" issues, aside from reverting back to 7.1.15, is to make manual modifications (never really recommended but ...) to the codebase to disable some new field validation mechanisms.

I don't think that the developers intention, when implementing the new validation enforcement features, was to seriously impede Espo's customization abilities, but unfortunately this has become a recurring issue, not just for manual customizations, but also for those executed via advanced pack (workflow and bpn) or by formula.

As a possible compromise (security vs flexibility) I proposed a feature to give the users the ability to set these new "strict validation mechanisms" on or off in metadata but nobody has responded yet. Hopefully yuri will consider it in future releases.

[yuri]

> is there are any fast fix or workaround

Uncheck read-only. Use dynamic logic to set read-only with any condition that resolves always to true.

> was to seriously impede Espo's customization abilities

I need concrete examples what is impeded. We don't have any issues with our systems. It's a big exaggeration that it 'seriously impeded' customization abilities.

[telecastg]

> I need concrete examples what is impeded

https://forum.espocrm.com/forum/general/82869-error-400-v7-2

[yuri]

Issues are easily solvable w/o changing code. No need to exaggerate the problem and manipulate. Validation rules are simple and easy to understand. Just need to get used to it.

It's like with the PHP language. It was a crap language for years and became decent one by introducing strictness But a lot of developers was always complaining that now that that language don't allow to write random code w/o getting errors.

[yuri]

> "strict validation mechanisms" on or off in metadata

It's already possible to disable validation in metadata (manually). https://github.com/espocrm/espocrm/b...nager.php#L251

[telecastg]

This is exactly what I was looking for, thanks for the hint. I am vey glad that it is already available.

[yuri]

Try setting validations you need, excluding not needed. I recommend setting both validationList and mandatoryValidationList in entityDefs.

[yuri]

> As a possible compromise (security vs flexibility) I proposed a feature to give the users the ability to set these new "strict validation mechanisms" on or off in metadata but nobody has responded yet.

Won't be implemented. Backend validation was there since long ago. We just added more validations in 7.2. We can't have a checkbox that will disable all the validations together.

BTW read-only has nothing to do with the validation.

[telecastg]

Regarding a metadata switch for validation, I meant what you have already implemented as noted above, not a wholesale disabling of all validations but a field level validation disable mechanism.

[yuri]

I meant disabling all validations for a field.

[yuri]

> But after upgrade to 7.2 system started ignore any other updates in backend because of read-only.

Can you provide details of your backend logic. This not supposed to be happening. The only difference is that read-only fields are stripped from the user input (it was intended by design but not implementer earlier due some compatibility issues).

For the test's sake. I created a field, made it read-only. Added formula that calculates it. Created a record. Field is calculated. Edited. Field is re-calculated.

Well. I've been working 14 hours today. I shouldn't have opened the forum a hour ago. It might be better for the product, my performance and sanity if I stop visiting the forum that regularly.

[esforim]

lol, don't be so stressful. Read some light heart thread instead.

[partomas]

Regarding read-only there are a sample:
there are field "Test" - by conditions or settings is set as "read only" and in UI is shown some value as not Editable - "Read Only"
After Save - using hook by php I try to change according some conditions. Before it was able to edit now - not.

In reality we don't need "read only" field in general, we need a field which is seen, but not editable by User via interface. It is used by system as informative "variable" only. As example - "recommended sales price" or updated Status of workflow or BPM actions to entity.

I hope now it's a bit more clear use cases we used "read only" field to eliminate values changes by user not by system. I understand a security aspect as well, so ideal solution could be another attribute to mark field as not editable in UI, but we can change it at backend level.

[shalmaxb]

For this use case you could also prevent editing the field by user role. In user role you can give permission even to fields.

[partomas]

I want to use dynamic logic and all other benefits of the CRM. Ideal solution to have two type of "Read only": one for UI another true "read only" fields