Redmine

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.").

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 2.2.2 that solved the problem for me.

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...