ikkez/f3-validation-engine

Upgrade to 1.6.0 breaks Validation Dependencies

Closed this issue · 4 comments

kumy commented

Coming from 1.5.0, upgrading to 1.6.0 break nested validation dependencies. Nested validator seems un-called.

An example class from our project

class EmailActivationToken extends Base {
    use \Validation\Traits\CortexTrait;
[…]

    protected $fieldConf = [
[…]
        'used' => [
            'type' => Schema::DT_INT1,
            'default' => 0,
            'nullable' => false,
        ],
[…]
        'updating_ip' => [
            'type' => Schema::DT_VARCHAR128,
            'nullable' => true,
            'validate' => 'required',
            'validate_depends' => [
                'used' => ['validate', 'email_activation_require_update'],
            ],
        ],
[…]

We expect the updating_ip field to be required only if our custom validator email_activation_require_update is True.

I've added some custom debug in email_activation_require_update, but code seems to never be reached.

Current code works fine with 1.5.0, 1.5.1 and 1.5.2.

kumy commented

Seems related to negation of statements, see comments there 035b92f

ikkez commented

Hi there. Sorry for the confusion.. I've checked that more than once again now and I still have the opinion that's the other way round. It wasn't just properly implemented yet. The documentation already said it correctly:

'foo' => [
	'validate' => 'required',
	'validate_depends' => [
		'bar' => ['validate', 'min_numeric,2']
	]
]

When the nested validation is TRUE (valid), then the dependency is met and the validation of foo goes on, otherwise it's skipped.

So if your custom validator returns TRUE, the validation is true and the field updating_ip becomes required... actually it's exactly how you expected it right now. Could it be that your custom validator isnt properly working? (check the 3rd True argument for type verification maybe?)

I noticed that this condition in 1.5 was wrong because some obvious examples did not work, including:

'contact_name' => [
	'type' => self::DT_VARCHAR128,
	'validate'=>'required|max_len,128',
	'validate_depends'=>['contact_surname'=>['validate', 'required']],
],

or something simple as

'foo' => [
	'type' => self::DT_VARCHAR128,
	'validate'=>'required',
	'validate_depends'=>['bar'=>['validate', 'empty']],
],

So if bar is empty, then foo becomes required. That's the way it should work and is working now in 1.6

kumy commented

Thanks for your feedback, I'll check my custom validator twice :)

If this is a breaking change, maybe that should be added to the release note, no ?

ikkez commented

well... it's not a breaking change actually.. it just has not worked correctly as described before ^^