Are you testing with an _administrator_ account? If yes, take a look at #11887#note-2 (quote: "Currently, admin users inherits workflow/fields permissions for all roles. So if the field is not required for at least one role, it's not required for admins. But if you set the field required for all roles, then it will be required for admin users too.").
--------------------------------------------------------------------------------
Mischa The Evil wrote:
> Are you testing with an _administrator_ account? If yes, take a look at #11887#note-2 (quote: "Currently, admin users inherits workflow/fields permissions for all roles. So if the field is not required for at least one role, it's not required for admins. But if you set the field required for all roles, then it will be required for admin users too.").

No i am testing with a normal user account. I believe that the problem is the type of field(version).
This field is required only same profiles, maybe if This field will required for all profiles ,can be work, but i didn´t test this situation.

--------------------------------------------------------------------------------
Mateus Anacleto wrote:
> Mischa The Evil wrote:
> > ...
>
> No i am testing with a normal user account. I believe that the problem is the type of field(version).
> This field is required only same profiles, maybe if This field will required for all profiles ,can be work, but i didn´t test this situation.

I've spent some time trying to reproduce this issue's report on m.redmine.org (~2.1.0) and I've found a way to do it. I'll outline it below.

This happens _only_ with a custom field with multiple allowed values (thus of the types @list@, @user@ or @version@), required for a certain role-tracker-status combination configured via Administration -> Workflows -> Fields permissions. In this situation a @nil@ value for the custom field is accepted during status transition (to a status on which a value for the custom field is required) of an issue on a configured tracker, by a user with the configured role. The visual indication besides the custom field is displayed as if a custom field value is indeed required, but it isn't.
The result is that the status transition *is allowed* with a @nil@ value for the custom field.

Configuring the custom field with multiple allowed values via Administration -> Custom fields -> _Custom field type_ -> _Custom field_ -> _Required_ (thus required for all role-tracker-status combinations) leads to a situation where @nil@ values for custom fields actually *are not allowed*.

Remaining question would be: is this by design or not?

Please let me know if there is more info needed...
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
The source of this problem is that the @validate_required_fields@ function for the @issue@ model does not check multiple custom field values in arrays.

I attached a patch based on Version version:2.2.2 that solved the problem for me.
--------------------------------------------------------------------------------
It looks like this problem is still present in the current trunk (r12230).
Is there a possibility to get this fixed in the next version?
How can I assist you in fixing this issue?
--------------------------------------------------------------------------------
If confirmed, then should be fixed with next version?
--------------------------------------------------------------------------------
Somebody just confirmed it on IRC. And it seems the patch works. The patch needs tests to ensure we don't introduce a regression later. I'll have a look at this unless somebody else wants it...
--------------------------------------------------------------------------------
Duplicated by #13891
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Needs feedback,13891,Field conditions depending on ticket status