Feature request: New validation rule prohibited_with

[Dmitrev]

There is currently no validation rule that allows you to say that if another field is present and not empty that it's prohibited.

We have kind of a unique use case, where the user can either give us their birth date (year or year + month) or they could give us an approximate age category if they are not comfortable to reveal their age.

Consider the following form data

[
    'birth_year' => 2000,
    'age_category' => '21+', // This field should not be allowed since birth year is given
]

This is currently no rule that can prohibit the current field if another field has a value.

The one that is closest to this is prohibits, the only issue with it is is that it would assign the error to birth_year. I would want to have an error that is associated with actual field that is at fault and needs to be corrected. So something like this would be ideal:

// rules
[
    'age_category' => 'prohibited_with:birth_year',
]

Further details in this comment

[ghost]

There is such a rule. https://laravel.com/docs/11.x/validation#rule-prohibits

[Dmitrev]

I think you must have missed the last paragraph of my post. prohibits technically achieves the validation requirement, however it will assign the error to the field that has prohibits on it, not on the field that is prohibited.

This is not ideal, because if you render errors by their key it will show to the user that the field that is technically correct as error.

but what I want is this:

but to be able to achieve that the error needs to be assigned to field B

There are a couple validations that almost do the exact behavior I seek:

missing_with - Requires the field to be completely missing, which is a bit annoying, because it would require me to every time filter the field out for the one key where it applies. as having null values is valid on most cases.

prohibited_if - Requires you to check some kind of value, in the docs they check for a bool true/false. This seems to have been created for cases when there is some kind of checkbox before entering some data.

so I think it's a good addition for completion.

[ghost]

I thought that this would be ok for you:

$rules = [
    'birth_year' => 'prohibits:age_category',
    'age_category' => 'prohibits:birth_year',
];

$messages = [
    'birth_year.prohibits' => 'Your message',
    'age_category.prohibits' => 'Your message',
];

[wizzymore]

What about "prohibited_if"? Isn't this what you want? You put it on the field that you want to prohibit so the error appears where you want.
The current field must be empty if the dependant field is not empty
https://laravel.com/docs/11.x/validation#rule-prohibited-if

[Dmitrev]

This not it, you can see my reply above. This rule requires 2 inputs, field name and value. So this wouldn't work.

[wizzymore]

Rule::prohibitedIf(!empty($request->get('other_input')))

Or if in a form group:

Rule::prohibitedIf(!empty($this->get('other_input')))

[ghost]

@wizzymore empty('0') is true. This is why I NEVER use it :). You can use

\is_string($input = $this->get('other_input', '')) && $input !== ''

[wizzymore]

Did not knew about that problem, thanks, good to know.

Doesn't that mean that the general solution would be more like: ( as is shorter and more readable and should do exactly what your code does )

Rule::prohibitedIf(!is_null($this->get('other_input')))

If not, please let me know why.

[ghost]

@wizzymore it depends on the validation from the input. If it must be only string and you send array or file then no.

[Dmitrev]

Did not knew about that problem, thanks, good to know.

Doesn't that mean that the general solution would be more like: ( as is shorter and more readable and should do exactly what your code does )

Rule::prohibitedIf(!is_null($this->get('other_input')))

If not, please let me know why.

Thanks I have never thought of using the Builder itself! On side note, you should avoid using get() on requests as that's using the Symfony request object which can cause some issues if you are hooking into requests like prepareForValidation

Always use ->input()
https://laravel.com/docs/11.x/requests#accessing-the-request

It's a bit confusing since most of the frameworks uses ->get() for everything, but this is a big Gotcha

[ghost]

@Dmitrev What problems are you referring to? You mean if you mess with the request via hooks and not via ->merge or ->replace, input returns spoiled request vs get returns initial or replaced/merged request?

[Dmitrev]

@marius-mcp Yes, and basically any additional stuff that Laravel layers on top you will be missing out on, but prepareForValidation is the best example I have for that. I believe also in some of the default middleware there are some additional parsing that Laravel does, all kinds of trims and type casts.

Unless what you want is the actual raw original request, you shouldn't be using ->get(). It's not supported by the framework, you will not find any mention of ->get() in the docs. It's available, because it just extends the default Symfony request object and they just didn't remove access to it.

The issues are rare, but can be an absolute pain to debug when you run into them. Default to just using ->input()