Redmine

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 ?

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.

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?

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.

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.

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.