Project

General

Profile

Actions

Defect #35132

open

Custum field default value has no effect if field is inaccessible

Added by Markus Boremski almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Custom fields
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

Unfortunately with 4.1.2 we now have an issue regarding #33550.
If we set a default value and the reporting person is not able to edit the field, the default value has no effect.


Related issues

Related to Redmine - Defect #33550: Per role visibility settings for spent time custom fields is not properly checkedClosedGo MAEDA

Actions
Actions #1

Updated by Bernhard Rohloff almost 3 years ago

  • Related to Defect #33550: Per role visibility settings for spent time custom fields is not properly checked added
Actions #2

Updated by Markus Boremski almost 3 years ago

Marius BALTEANU wrote #33550#note-28:

Yes, please. I'll try to catch the fix in the upcoming 4.1.3 which will be release at the end of this month.

Could you please take this one into account for 4.1.3 ?

Actions #3

Updated by Marius BĂLTEANU almost 3 years ago

Sorry Markus, I totally forgot about this.

Is the custom field visible to the user's role? If not, is the expected behaviour because the custom fields not visible to user's role are not taken into consideration at all, regardless if they have a default value or not. You can check this behaviour for other types of custom fields (Issue for example).

If you want to have a default value for that field, I think you should make first the field visible to that specific role and then make it read only from Workflow.

Actions #4

Updated by Markus Boremski almost 3 years ago

Sorry Markus, I totally forgot about this.

No problem.. :)

Is the custom field visible to the user's role?

No. It issn't.

Our Usecase:
We have a custom field for spent-time. It is a boolean that saves if the spent-time has been exported to an external ERP-System.
We have an external script that reads booked hours and exports them. The custom value is needed to let the script know if a single time-entry already has been exported. The user dont need this information so this value is invisible to everyone except administrators.

In 4.1.1 our usecase worked like a charm.
Since 4.1.2 I have to set default-values manually day to keep the script going.

If not, is the expected behaviour because the custom fields not visible to user's role are not taken into consideration at all, regardless if they have a default value or not.

Sure, we can talk about the type of this issue here and change it from defect to something else.
But I don't see why default values are not taken into account if a field is invisible to a role.

Side-question:
Could anyone maybe give us a patch to make functionality like 4.1.1 again or just give us a hint where to edit this?

Actions #5

Updated by Marius BĂLTEANU almost 3 years ago

Markus Boremski wrote:

Side-question:
Could anyone maybe give us a patch to make functionality like 4.1.1 again or just give us a hint where to edit this?

It should be enough to remove the below code from source:trunk/app/models/time_entry.rb#L132

# Delete assigned custom fields not visible by the user
editable_custom_field_ids = editable_custom_field_values(user).map {|v| v.custom_field_id.to_s}
self.custom_field_values.delete_if do |c|
  !editable_custom_field_ids.include?(c.custom_field.id.to_s)
end

Please be aware that I didn't test this change.

Anyway, my recommendation is to create a basic plugin that adds a new column to the time_entry table with "No" as default value and change your scripts to use this new column, but some Rails and Redmine skills are required.

Actions #6

Updated by Markus Boremski almost 3 years ago

It should be enough to remove the below code [...]

Thank you. Thats worked perfectly.. :)

Anyway, my recommendation is to create a basic plugin [...]

Thank you for your recommondation.

Can we discuss the rootcause here too pls:

I don't see why default values are not taken into account if a field is invisible to a role.

Actions #7

Updated by Marius BĂLTEANU almost 3 years ago

Markus Boremski wrote:

Can we discuss the rootcause here too pls:

I don't see why default values are not taken into account if a field is invisible to a role.

I suppose that was a design decision when custom fields visibility was introduced (#5037). In my opinion, the behaviour it's correct because a user should interact only with visible custom fields. Regarding your use case, it's valid, but it should be implemented in another way, maybe with an option to mark a visible custom fields ready only or writable by specific roles.

Actions

Also available in: Atom PDF