When add a custom field, you decide when to include it into issues. Only those marked with prompt when creating new issues will be added to an issue when it is opened. For others, you can configure it to show in state transition rule. For instance, you may have a custom field only applicable when issue is transited to "pending review", etc.

@robin The problem is that if adding an issue by using the + sign on the Backlog list, it does not get that custom field, therefore one is not able to drag it to the columns with the fields and move it to "pending review".

It seems that if I add the issue from the + in one of my columns (instead of Backlog), then it does get the field, and then I can then drag it to the other columns.

Personally, I find it very confusing that issues do not have the fields at all, even though I did specify a Default Value for that field in the custom field setting.

I would always expect to be able to set any of the custom fields from the regular issue editor, without having to resort to the Batch editing functionality.

There is also refresh issues with dragging to another column. Sometimes it never refreshes. When it does refresh, it takes a very long time (like 5 seconds with a small number < 300 of issues still) and a lot of distracting visual refreshes which are a major pain when sorting through hundreds of issues. I would not expect the visual update to wait on a response from the server to perform the UI update when dragging a card from one column to another.

Not all custom fields are expected to show on each issue, as mentioned some are only applicable for certain states, and some should be shown if some other custom field has certain value...

For your case of custom field not being populated for issues added via backlog column, please tell me steps to reproduce it.

@robin Simply click + on the backlog column (switched on by toggling Backlog button), and add an issue this way. It doesn't get the custom field.

But if I use the + from a custom field-based column (I have a board with 4 of these columns named: selected, started, review, done), if I click the + from one of these column they do get the custom field with the value set to that column, and I am able to simply drag the card to another column to change the value of that custom field.

I cannot drag the issue that I add from Backlog +, since it doesn't get the field (even though the custom field is set to have a Default Value to the first column selected).

I guess you do not tick the "prompt upon issue open` option when define the custom field? In your case, you will need to tick that option.

@robin I did not, because I did not want the user to enter it when creating the issue. Only being able to add it afterwards in issue details or by dragging to column.

It is very confusing if that is required in order to be able to get the field at all in issue details or when dragging to a column that should "add" the field.

In general, I find it extremely confusing and cumbersome that a custom field is not automatically present in an issue.

That is, there is a distinction between "missing field" vs. "empty field", even when the custom field has "Allow empty" set, and issues where "prompt upon issue open" was not selected have a "missing field", just like isssues created before the new custom field was set up.

It seems that not selecting "prompt upon issue open" is equivalent to new issues not getting the field at all, with the only possible way to add the field being using the "Batch edit" functionality, which is very tedious compared to opening the issue itself or the ... quick-edit dialog to easily set the field value.

Normally you should tick the prompt upon issue open option. Leaving it unchecked only if this field should be added when issues are transited to other states. You can give a sensible default for this field so that user does not need to fill the field when open the issue.

Other products generally do not have this option, as custom fields defined will always appear in issue, without the flexibility to let you control which state should contain which field.

Batch edit should only be used rarely, and is not part of issue workflow.

Batch edit should only be used rarely, and is not part of issue workflow.

I agree, but that is the only way to add those fields if you did not select prompt upon issue open.

At the very least I think the name of that option is very misleading.

It should be called something like "enable this field when issue is created", since it is not only about whether the option is presented to the user in the create issue dialog. (nothing to do with "prompting" the user)

Makes sense, will change the description as you suggested.

Awesome, thank you! OneDev is really amazing and powerful for Kanban once you understand how it works, so it's great if users can get up and running easily!

State changed as code fixing the issue is committed (adf69ec6)

State changed as build #3540 is successful