Defect #12146

Required (list-, user- or version) custom field "fixed version" with Multiple values allows nil value during status transition

Added by Mateus Anacleto almost 5 years ago. Updated over 1 year ago.

Status:ConfirmedStart date:
Priority:NormalDue date:
Assignee:Jean-Baptiste Barth% Done:

0%

Category:Custom fields
Target version:Candidate for next minor release
Resolution: Affected version:2.5.2

Description

I created a custom field (type Version) called "fixed version" to be filled in at the close of a task.

Using a workshop to force a filled in field based on the situation:

Type Situation Status
Custom Field Version with Multiple values new not required
Custom Field Version with Multiple values closed required

If the task was created with a situation when the field is not required (new) and you change for a situation that the field is required (closed), the rule don´t work and allows saving without filling in the field that should be required in this situation.

Environment:
Redmine version 2.1.2.stable
Ruby version 1.8.7 (x86_64-linux)
Rails version 3.2.6
Environment production
Database adapter MySQL
Redmine plugins:
redmine_inline_attach_screenshot 0.4.2

11_correct_bug_with_required_cf_with_multiple_values.patch Magnifier (1.12 KB) Jürgen Diez, 2013-09-18 09:43


Related issues

Related to Redmine - Feature #13891: Field conditions depending on ticket status Needs feedback

History

#1 Updated by Mischa The Evil almost 5 years ago

  • Subject changed from Mandatory custon field "fixed version" with Multiple values to Mandatory custom field "fixed version" with Multiple values

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

#2 Updated by Mateus Anacleto almost 5 years ago

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.

#3 Updated by Mischa The Evil over 4 years ago

  • Status changed from New to Confirmed

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

#4 Updated by Mischa The Evil over 4 years ago

  • Subject changed from Mandatory custom field "fixed version" with Multiple values to Required (list-, user- or version) custom field "fixed version" with Multiple values allows nil value during status transition

#5 Updated by Jürgen Diez almost 4 years ago

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.

#6 Updated by Jürgen Diez over 3 years ago

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?

#7 Updated by Etienne Massip almost 3 years ago

  • Priority changed from High to Normal
  • Target version set to Candidate for next minor release

If confirmed, then should be fixed with next version?

#8 Updated by Jean-Baptiste Barth almost 3 years ago

  • Assignee set to Jean-Baptiste Barth
  • Affected version changed from 2.1.0 to 2.5.2

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

#9 Updated by @ go2null over 1 year ago

Duplicated by #13891

#10 Updated by Toshi MARUYAMA over 1 year ago

  • Related to Feature #13891: Field conditions depending on ticket status added

Also available in: Atom PDF