Custom Validation Approach
Permalink
Hello all,
I am wondering what the correct approach is for creating some custom validation logic.
Here's the problem:
We collect a DOB on registration and have to validate that it falls between a max and min date. The max and mix are determine at the time of registration i.e. we only want to register users between the age of 15 and 22.
However at a later date, we may want to edit a user's DOB and the validation does not have to apply.
How can I achieve this using a custom attribute (or an alternative)? I'm struggling with how can the attribute know when registartion has occured?
Just looking for some guidance - pointers in the right direction.
Thanks,
Gordon
I am wondering what the correct approach is for creating some custom validation logic.
Here's the problem:
We collect a DOB on registration and have to validate that it falls between a max and min date. The max and mix are determine at the time of registration i.e. we only want to register users between the age of 15 and 22.
However at a later date, we may want to edit a user's DOB and the validation does not have to apply.
How can I achieve this using a custom attribute (or an alternative)? I'm struggling with how can the attribute know when registartion has occured?
Just looking for some guidance - pointers in the right direction.
Thanks,
Gordon
Thanks JohntheFish,
Fortunately the business process doesn't allow for users to change their own details - we use the registration form to gather potential clients, then any changes after that are made by (almost) admin users manually. Hurrah!
So the two forms approach sounds like the best for my purposes. However I thought it would be two views of the same custom attribute, but then when I went to write the code I realised the validation is run within the attribute's controller. So it doesn't matter which view I use the attribute will still be validated in the same way.
Still confused,
Gordon
Fortunately the business process doesn't allow for users to change their own details - we use the registration form to gather potential clients, then any changes after that are made by (almost) admin users manually. Hurrah!
So the two forms approach sounds like the best for my purposes. However I thought it would be two views of the same custom attribute, but then when I went to write the code I realised the validation is run within the attribute's controller. So it doesn't matter which view I use the attribute will still be validated in the same way.
Still confused,
Gordon
In the custom attribute validation, make a decision based on the user group of the current user. Pseudocode:
You could do this in JavaScript on the attribute form, or in PHP in the attribute controller save/validate. PHP may be a better place for testing the user group.
You could take a regular attribute and override the controller.
if (! user in manager_group){ check_in_restricted_range(); }
You could do this in JavaScript on the attribute form, or in PHP in the attribute controller save/validate. PHP may be a better place for testing the user group.
You could take a regular attribute and override the controller.
- 2 different forms for editing, one with the tighter validation.
- 1 form with validation code that adapts the limits to who is making the input (admin or registered user).
Both methods could fall fowl of subsequent edits by the original user when the value has already been changed by the admin. In many ways, this is more of a business process problem than a technical one.