Can confirm this defect on 4.1.1
Also can confirm that #33550#note-1 fixes this defect.

Markus, I expect experience that even with the patch, a role that do not see the custom field is not able to submit time spent anymore, even though he should be able to. Can you also confirm that unexpected behavior ?

Mischa, did you have an opportunity to have a look at this ?

Markus, I expect that even with the patch, a role that do not see the custom field is not able to submit time spent anymore, even though he should be able to. Can you also confirm that unexpected behavior ?

We have one field that is required, but it has a default value.
The second field is not requiered and does not have a default value.
This works fine so far.

On our system I can not validate this behavior mentioned by #33550#note-2.
But it sounds logical to me that in case of a reqiered field without a default value there might be an issue with this patch.

Indeed I should have mentioned that my custom field is required but does not have a default value. That might seems a bit unusual, but I feel our use case is reasonable.

Our custom field is meant to select to which customers the time will be billed. Reporters should not be aware of that at all. So we'd like to hide the field for them. On the other hand we want developers to select which customers to bill. It must be billed to someone, so it is required. And we want to force the developers to make a deliberate choice. We cannot say "by default it will be billed to Customer A". So we cannot have a default value.

That makes sense to me. But maybe there's a different way to approach this.

Then you could say that in most cases the reporters probably would not need to log time. So we could live with the patch for a while. But that feels a little bit inconsistent behavior. It's showing a form that can never be valid. Sounds like a bug to me, or at least a suboptimal situation.

Adrien Crivelli wrote:

Markus, I expect that even with the patch, a role that do not see the custom field is not able to submit time spent anymore, even though he should be able to. Can you also confirm that unexpected behavior ?

Yes, it's an unexpected behaviour. A custom field not visible for the user should not be required.

I've fixed the first issue (spent time custom field always visible in issue#edit), I'll continue to work on the second issue. In the meantime, I've assigned this issue to 4.1.2 in order to deliver the fixes as soon as possible.

Adrien Crivelli wrote:

I only noticed a small visual inconsistency when submitting an invalid form where custom fields are not highlighted in red like other fields. If you think this is unrelated and should be addressed separately (I think it should be), I'll gladly submit a new issue.

Thanks Adrien for testing the fix. Please open a new issue for the inconsistency, I took a look and is not an easy fix.

Marius BALTEANU wrote:

Adrien Crivelli wrote:

I only noticed a small visual inconsistency when submitting an invalid form where custom fields are not highlighted in red like other fields. If you think this is unrelated and should be addressed separately (I think it should be), I'll gladly submit a new issue.

Thanks Adrien for testing the fix. Please open a new issue for the inconsistency, I took a look and is not an easy fix.

I've created the issue and I've added a fix for it, please see #34580.

The test fails in 4.1-stable branch. I have not found the cause yet.

$ bin/rails test test/functional/issues_controller_test.rb:4878
Run options: --seed 30553

# Running:

F

Failure:
IssuesControllerTest#test_get_edit_should_display_visible_spent_time_custom_field [/Users/maeda/redmines/4.1-stable/test/functional/issues_controller_test.rb:4890]:
Expected exactly 1 element matching "#issue-form select.cf_10", found 0..
Expected: 1
  Actual: 0

bin/rails test test/functional/issues_controller_test.rb:4878

I will take a look.

r19690 unified custom fields classes on 4.2.0 and the class used to assert the element doesn't exist in older versions.

Please apply the following changes:

diff --git a/test/functional/issues_controller_test.rb b/test/functional/issues_controller_test.rb
index ff7c564ae..e9e0cc255 100644
--- a/test/functional/issues_controller_test.rb
+++ b/test/functional/issues_controller_test.rb
@@ -4887,7 +4887,7 @@ class IssuesControllerTest < Redmine::ControllerTest

     assert_response :success

-    assert_select '#issue-form select.cf_10', 1
+    assert_select '#issue-form select#time_entry_custom_field_values_10', 1
   end

   def test_get_edit_should_not_display_spent_time_custom_field_not_visible
@@ -4907,7 +4907,7 @@ class IssuesControllerTest < Redmine::ControllerTest

     assert_response :success

-    assert_select '#issue-form select.cf_10', 0
+    assert_select '#issue-form select.#time_entry_custom_field_values_10', 0
   end

Test passes after this change:

root@3d6d6070185e:/work# ruby test/functional/issues_controller_test.rb -n test_get_edit_should_display_visible_spent_time_custom_field
Run options: -n test_get_edit_should_display_visible_spent_time_custom_field --seed 7576

# Running:

.

Finished in 2.137915s, 0.4677 runs/s, 0.9355 assertions/s.
1 runs, 2 assertions, 0 failures, 0 errors, 0 skips

Unfortunately with 4.1.2 we now have an issue regarding this fix.
If we set a default value and the reporting person is not able to edit the field, the default value has no effect.
Should I report a new issue?

Markus Boremski wrote:

Unfortunately with 4.1.2 we now have an issue regarding this fix.
If we set a default value and the reporting person is not able to edit the field, the default value has no effect.
Should I report a new issue?

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.

Done -> #35132
Could you please edit title if necessary and maybe link over here.
TY