https://www.redmine.org/https://www.redmine.org/favicon.ico?16793021292015-10-29T13:28:19ZRedmineRedmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=669382015-10-29T13:28:19ZJean-Philippe Langjp_lang@yahoo.fr
<ul></ul><p>Couldn't we just do:</p>
<pre>
Index: app/models/custom_value.rb
===================================================================
--- app/models/custom_value.rb (revision 14752)
+++ app/models/custom_value.rb (working copy)
@@ -22,7 +22,7 @@
def initialize(attributes=nil, *args)
super
- if new_record? && custom_field && (customized_type.blank? || (customized && customized.new_record?))
+ if new_record? && custom_field
self.value ||= custom_field.default_value
end
end
</pre>
<p>That would fix this issue and set the default value as well for custom fields that are added after an issue is created.<br />Is there any problem with that?</p> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=669582015-10-30T09:47:12ZHolger Just
<ul></ul><p>This was my first guess too. I'm slightly concerned however, that this could change the custom fields on save too. Right now, <code>nil</code> and the empty string seems both to be valid values for the "blank" value of non-required custom fields.</p>
<p>While your proposed patch solves the immediate problem, it might have undesired side-effects when people send <code>nil</code> as a custom field value, e.g. via the API or by omitting the field value in a request.</p>
<p>You could argue that this is the desired behavior, i.e. sending <code>nil</code> results in the default value being set. But it would change existing behavior here and might break certain API use-cases where users send <code>nil</code> instead of an empty string and expect the blank value to be set. After having thought about this for a bit longer, it is however probably worth the change, as it makes the final behavior more obvious and consistent.</p>
<p>Thus, finally, +1 from me for your proposed patch.</p> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=669792015-10-31T09:18:04ZJean-Philippe Langjp_lang@yahoo.fr
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li><li><strong>Assignee</strong> set to <i>Jean-Philippe Lang</i></li><li><strong>Target version</strong> set to <i>3.2.0</i></li><li><strong>Resolution</strong> set to <i>Fixed</i></li></ul><p>Thanks.</p> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=781992017-04-25T17:16:54ZJens Krämerjk@jkraemer.net
<ul><li><strong>File</strong> <a href="/attachments/18165">0001-do-not-display-default-values-that-aren-t-actually-s.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/18165/0001-do-not-display-default-values-that-aren-t-actually-s.patch">0001-do-not-display-default-values-that-aren-t-actually-s.patch</a> added</li></ul><p>Actually I think there is a problem with this.</p>
<p>Steps to reproduce:</p>
<ul>
<li>Create a new issue.</li>
<li>Create a new boolean issue custom field with a default of yes or no and <em>use as filter</em> set.</li>
<li>look at the previously created issue in issues list (have the custom field displayed) and detail view</li>
<li>note the different values being shown for the custom field - issue details page shows the configured default, while the issue list shows the field as unset (empty).</li>
<li>When filtering the issue list for the field's value (or simply looking at the database) it turns out that the field is indeed unset (neither filtering for the field being 'yes' or 'no' turns up the issue). So clearly the details view is lying about the field's true value by replacing <em>unset</em> with the configured default.</li>
</ul>
<p>I think this also applies to other field formats, not just booleans.</p>
<p>Imho the default value for unset custom fields (where no corresponding custom_value record exists) should only be preset in the edit form, but not when merely showing the issue details. I came up with a patch that checks if there is actually any custom value present in the database for the given field before calling <code>show_value</code>, but to be honest I'm not very happy with that.</p> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=782042017-04-26T02:06:26ZMischa The Evil
<ul></ul><p>Jens, your comment made me re-read this whole issue and it reminded me of an issue I encountered and reported a long time ago (<a class="issue tracker-1 status-1 priority-5 priority-high2" title="Defect: Custom field values of several issue custom field formats don't get set/updated properly during e... (New)" href="https://www.redmine.org/issues/9849">#9849</a>). As of today I don't know whether or not that issue is still present and still reproducible (and I'm currently unable to test this vigorously), but I can't help thinking it might be related to this issue in a sense. So to be sure, I post this comment to bring that issue to the attention within the context of this current issue.<br />However, since this issue has been closed targeted against 3.2.0, it might be a better idea to create a new issue altogether...</p> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=782652017-04-28T15:14:00ZJens Krämerjk@jkraemer.net
<ul></ul><p>posted as new issue <a class="issue tracker-1 status-5 priority-5 priority-high2 closed" title="Defect: Issue details page shows default values for custom fields that aren't actually set (Closed)" href="https://www.redmine.org/issues/25726">#25726</a></p> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=789842017-06-02T10:14:25ZMischa The Evil
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-5 priority-high2 closed" href="/issues/25726">Defect #25726</a>: Issue details page shows default values for custom fields that aren't actually set</i> added</li></ul> Redmine - Defect #21074: When changing the tracker of an existing issue, new custom fields are not initialized with their default valuehttps://www.redmine.org/issues/21074?journal_id=791022017-06-09T04:02:04ZMischa The Evil
<ul></ul><p><a class="user active" href="https://www.redmine.org/users/13581">holger mareck</a>: as being the OP of this issue, do you maybe have have some ideas on <a class="issue tracker-1 status-5 priority-5 priority-high2 closed" title="Defect: Issue details page shows default values for custom fields that aren't actually set (Closed)" href="https://www.redmine.org/issues/25726">#25726</a>? What do you think about the solution of handling custom field default values as proposed by Jens?</p>