[7.0] [add] fields validator

[eLBati]

This module allows to set a regular expresion as field validator.
When the regular expresion is set, write and create operations on the involved
field are blocked, if the regular expression is not satisfied.
See demo and test data for an example with partner email.

[pedrobaeza]

Hi, @eLBati, thanks for the module. I think a better name for it is base_field_validator

Entering in the functionality, I feel that this kind of things must be done client-side (in JS widgets), not server-side. In this direction, there is this PR OCA/web#34 and collides in functionality with this one. We should decide in which direction go.

[eLBati]

Hi @pedrobaeza thanks for pointing it out (I don't follow https://github.com/OCA/web enough 😔)
It is fine for me to add web_fields_masks only.
We are going to test it.

[eLBati]

Not sure if web_fields_masks supports regex (OCA/web#34 (comment)). It seems it does not

[coveralls]

Coverage increased (+2.82%) when pulling 68461c9 on eLBati:7_add_fields_validator into e6f0c68 on OCA:7.0.

[eLBati]

Just to notify that this needs review (can't edit labels)

[pedrobaeza]

Don't you think it's better to add (or check) regex support on the other PR. This is to follow with my thought about having this kind of checks client-side.

[lmignon]

@pedrobaeza IMO, the client side would stay without business logic... (and field validation is part of the business logic). If I understand well the PR OCA/web#34, the validation doesn't prevent to save the value. In this PR, the validation is enforced even on the server side. I've the feeling that this PR covers another UC. What do you think?

[pedrobaeza]

I think this is not business logic, but basic validations. Check for example HTML forms: this kind of validations (mandatory fields, numeric values, etc) are made always client side.

[nhomar]

I think exactly as @lmignon It is a good feature, if you go throught a customized clients over web-servides the OCA/web#34 will be jumped.

+1 to have it in both sides (we need both).

Client side:

To avoid the POST that consume time and make a uncommit of the changes.

Server side:

To be consistent thoruhgt web-services.

On my side a total +1 "Conceptually Speaking" to this PR.

[lmignon]

For sure the validation on the client will leverage the User experience and avoid unnecessary calls to the server. But it's the responsibility of the server to enforce the data consistency whatever they are modified (by a request from the browser or from web-services or even internal calls). Conceptually the concept of validator sounds good. One step further would be to leverage the fields_view_get from BaseModel to add the validator definition in the field description send to the JS client and implement the validation also on the client side.... (I've a dream...)

[pedrobaeza]

Yeah, we'll have to put it as wishlist.

@eLBati, please consider following remarks then and I'll approve it:

• Change name to base_field_validator
• Add a know issue / roadmap section in description about the lack of client side check.

[eLBati]

Thanks for the reviews
@pedrobaeza done

[pedrobaeza]

👍 Thanks

[yvaucher]

commits from hurrinico are not well defined, it is certainly missing email in author

Can you amend them?

[eLBati]

On 2 June 2015 at 17:33, Yannick Vaucher notifications@github.com wrote:

commits from hurrinico are not well defined, it is certainly missing email
in author

Can you amend them?

Amended!

[tafaRU]

s/expresion/expression

[eLBati]

Done, thanks

[yvaucher]

👍

[eLBati]

I think this can be merged

[hbrunn]

I think you should return whatever old_write returns

[eLBati]

@hbrunn thanks, I made the proposed changes.
Now I try to find out why travis failed

[eLBati]

Ok, my bad. Now travis is green 💚

[eLBati]

@OCA/tools-maintainers please set this 'needs review'

[StefanRijnhart]

As on the 8.0 PR, better not to change the signature of _register_hook

[guewen]

Can we merge this PR?

[gurneyalex]

👍