Feature #2183


Avoid potential awkwardness in adding custom boolean fields to existing projects

Added by Bobby Birks over 15 years ago. Updated over 11 years ago.

Custom fields
Target version:
Start date:
Due date:
% Done:


Estimated time:


This issue was noted on a Redmine 0.7.3 install.

Not sure how this can be resolved, but we already had several hundred issues when I added a custom boolean field to a project (to flag ongoing support issues that would last until some new feature was implemented or bug fixed). I defaulted the value to false, but none of the existing issues were updated.

Note that I don't have an issue with this behavior -- having no value at all can make it easier for people to perform a cleanup phase, for example. Granted, it might be nice to have the option of applying the default value to all existing issues, but forcing it could be a mistake.

The value was effectively null. However, anyone updating the issue would, if they took no special action, set this value to false (because the checkbox was unchecked for such issues). Users simply logging time on an issue via Update (rather than the log time screen) would set the value to false without realizing it. It would show up in the change log (and send e-mails), but they wouldn't notice until after the fact. (This didn't affect us much, since in most cases we wanted the value to be false anyway.)

However, while working on a filter to exclude these issues, I noticed that "Is No" omitted not only issues where the value was true, but also issues where the value was not provided. This is perfectly reasonable for a system whether no values ever equal null, but less technical users might not understand such reasoning. I worked around it by making an "Is Not Yes" filter instead, which had the effect I desired.

This also leads to the idea that a cleanup phase for a new field could be rather tedious or counterintuitive. For example, to get a list of issues that have a null for this boolean value, one requires an "Is Not Yes or No" filter and someone to step through and update those issues individually.

I think some of the issues could be resolved by allowing someone to apply a default value if they wished to. The rest I have no real suggestions for, as adding the ability to filter by "yes, no, none" on a boolean value might seem...stranger still.

Actions #1

Updated by Daniel Felix over 11 years ago

+1 for this feature.

I currently expected the same behaviour.

With the abbility to "push" those default value to every databasefield which is "null" (just a simple update query) would be great!
existing fields shouldn't be updated.

For example:
SET t.customfield = 'Default'
FROM TableWithCustomFields AS t
WHERE t.customfield IS NULL


Also available in: Atom PDF