Defect #35132

Custum field default value has no effect if field is inaccessible

Added by Markus Boremski 5 months ago. Updated 5 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Custom fields
Target version:-
Resolution: Affected version:4.1.2

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

History

#1 Updated by Bernhard Rohloff 5 months ago

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

#2 Updated by Markus Boremski 5 months 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 ?

#3 Updated by Marius BALTEANU 5 months 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.

#4 Updated by Markus Boremski 5 months 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?

#5 Updated by Marius BALTEANU 5 months 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.

#6 Updated by Markus Boremski 5 months 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.

#7 Updated by Marius BALTEANU 5 months 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.

Also available in: Atom PDF