6 | | One nice side effect of eliminating `[ticket] default_owner` will be eliminating the `< default >` value, which is awkward due to the whitespace, and it's not obvious that the value should result in the //Component// owner being set: comment:7:ticket:7979, comment:8:ticket:10825. |
| 6 | One nice side effect of eliminating `[ticket] default_owner` will be eliminating the `< default >` value, which is awkward due to the whitespace, and it's not obvious that the value should result in the //Component// owner being set: comment:7:ticket:7979, comment:8:ticket:10825. However, even with a `set_owner_to_component_owner` operation we'd still need to allow `< default >` for `default_owner` if we wish to have the drop-down default to the component owner (as opposed to having a workflow action that strictly assigns to the component owner). |
| 7 | |
| 8 | If `[ticket] default_owner` is moved to the ticket workflow then `[ticket] default_resolution` should be handled similarly. |