Error 400 v7.2

[telecastg]

You're welcome abisbe

[abisbe]

Awesome! Big thanks telecastg

[telecastg]

UPDATE: This issue has been successfully resolved by allowing the back end field validation feature to be controlled by the user, not just by the system defined criteria, in keeping with Espo's tradition of great ease of customization.

Big Thanks !

https://forum.espocrm.com/forum/developer-help/developer-tutorials/88484-how-to-disable-back-end-field-validation-to-avoid-the-field-validation-error#post88498

[abisbe]

Hi Yuri, maybe not. But in our case, we were counting on that behavior, and suddenly having this change required a ton of checks and modifications, not on any customization, but on enum fields that we were using "the old way" and that we were not considering it incorrect.

[yuri]

> They take away one of Espo's greatest strength which is its ease of customization.

This is a manipulation (that I don't like).

The validations exposed customizations made not properly. After fixing them all will be working. Fixing them should not be a big deal.


* Read-only fields are stripped when posting forms.
* Enum fields accept only values explicitly allowed for the field.
* ID values should match the defined regexp pattern (that you can change in metadata).

Are these making Espo less customizable?

[yuri]

You send some non-ID data in the field that is supposed to receive IDs or you use non-standard IDs. If you use non-standard IDs, consider changing allowed ID regexp pattern in the metadata.

What is immature with the validation in this case? You don't consider the customization immature, but the validation.

[yuri]

> Rules are not documented.

What exactly is not documented. Please provide concrete example what is not documented and what is not clear.

[telecastg]

The problem with this new enforcement mechanism is in my opinion:

1) Rules are not documented, no matter how much "sense" they might make to the developers, the vast majority of users need to know, without having to dive into the codebase, what these rules are for each type of field and how not to "violate" them.


2) They take away one of Espo's greatest strength which is its ease of customization, not just by coding but by very userf friendly facilitiess like BPN, workflows and formula.

[abisbe]

hi all, we had this very same issue upon updating yesterday to the newest version. And it was solved at ESPO by changing and then changing back the requirement of that field. I know it's not a super accurate answer, but probably something got "stuck" on the definition of that field.

[telecastg]

You're very welcome

[rabii]

seems that solved the issue as you said i have deactivated code for checking validation pattern until it is mature and works better.

thanks for putting me into the right direction.

[telecastg]

If the field "Tipo de Motivo" is enum and you don't want to have static options (hard coded in metadata) set the "options" parameter for the field as "null", this way the validator will not trigger any errors based on the values of the field.

I had the same case for a field where the options are defined dynamically based on the value of a different field.

[telecastg]

I think that the problem might be because the field contractServices is defined as a field type link multiple and the system might be expecting an array of ids of the records that make the "many" side of the relationship (thus the "pattern error") ....

For general information, when a link multiple relationship is created, for example like One to Many, the entity in the "One" side will have two additional attributes that contain the information about the "Many" linked entities.

For example: I have a custom "Control Board Display" entity that is liked to many "CriteriaConditiionGroup" entities, and when I look at the "ControlBoardDisplay" model in the console, it has the attributes "criteriaConditionGroupsIds" containing a list of the ids of linked CriteriaConditionGroup entities and the attribute "criteriaConditionGroupsNames" containing the names of the linked CriteriaConditionGroup records.

So even though, I did not create or specify a field "criteriaCondiitionGroupsIds" in metadata, the system created it when building the links, and the validation enforcement for that field will check that the ids conform to the regex pattern specified by Espo.

This is the code performing the link multiple pattern validation: https://github.com/espocrm/espocrm/b...leType.php#L66

Because of the time spent attempting to solve these issues, given the lack of documentation, in our case, we have opted to wait out before moving forward with 7.2 until this new "validation" enforcement mechanism is more mature and understood so we can adapt our code appropriately.

Aside from that option, the other alternative at this time, would be to remove/block the code that adds the validation for now.

[rabii]

I have already went that way but there was no pattern on the field. Tried few different ways but seems that none has worked. Main issue is the service field on contractservice entity the system report that it is undefined array key ‘service’.

[shalmaxb]

The error says it is because a problem with the pattern. This was recently introduced in 7.2. In the entity manager you will see now in the field a new value "pattern", which makes possible to enter a certain mandatory pattern like e.g. 4 digits or alike. Have a look in the shown fields, if you could put in an appropriate pattern and see, if that solves the problem.

As this value did not exist before, it is not present in existing records. Maybe (maybe!) in this direction you could solve the problem.