When you install the software development app, it starts with “Severity” and “Priority” single-select fields on the Bug type. The options have names like “High”, “Medium”, “Low”, but they also have a number value that’s accessed in a “Pain” formula.
I’d like to do something similar for the Effort field, but I can’t find the option to set/edit the number value in the UI, and the API is vague on how to create an enum with number values. My schema has “Development/Value” as a type, but when I try to create an enum that uses it I get “Field Development/Value was not found in type Development/Effort_Development/Story.”
Is there a way to set these number values using the API?
This is tricky. You can add Value field to Single Select as shown below. In fact Single Select is just a Type under the hood and you can add as many fields as you wish and access them via Formulas or API
This is a great feature. Wish I’d known about it sooner.
Given that a single-select is just a type under-the-hood, is it possible to link a single-select field to more than one parent type? Or even the same type more than once?
Sometimes it’s useful to have the enumerations defined once but used several places…
Also, @mdubakov is multi-select also just a type under-the-hood? Seems like it.
Just wondering, if I wanna assign a single-select value in a formula, for example to update the state of a Feature based on all the User Stories in it (i.e. once all US are Done, mark the Feature as Done).
I do not see how this answer solves that? I remember @ChrisG highlighting that I can give single-select options additional fields, which is great, but I don’t think I can select them in a formula.
It does seem to me that I can use this workaround:
Assuming you have Feature → User Stories, then I can think of a couple of ways to do it:
You can have an automation in the User Story db that runs when the state becomes Done, and updates the parent Feature’s State (based on a formula that checks that there are no linked User Stories that are not done, and if so, sets the State to Done). This would use a construction like you have shown.
You can have a formula in the Feature db, e.g. [User Stories].filter(State.Name = 'Done').Count() = [User Stories].Count() and then an automation to update the Feature State to Done when this is True.
That said, it still doesn’t feel neat, because what I want is:
Have an automation that updates the Feature whenever a User Story state changes: It’ll check if the parent Feature has any remaining open User Stories and if not, sets the Feature to Done.
The problem is: If I use a formula to check for open user Stories, I need to assign the Done state from the formula. That is only possible with the convoluted construct from my screenshot, where I filter for a Feature with my intended state and assign that… (as you say in your answer #1)
Your solution 2 would allow me to do a static assignment of Done in the Feature, which is neat. But it then convolutes my database with a formula that’s not really providing any data value, but is needed for working around a tooling limitation. This is clearly not desirable long-term.
In the end, the most elegant approach would be to be able to refer to specific states (single/multi-select options) in a formula. For example via Features.States.Done or a similar syntax. This also has the advantage that it’ll break and throw errors, when the states get modified.
You’re right, that both my suggestions are sub-optimal. I know that @antoniokov is aware of this use case, and it is likely that we will support the ability to set a state just by assigning a string. in this case you could use suggestion #1 without needing the convoluted workaround.
Well, I kinda glossed over how we are thinking of implementing it by saying ‘string’. It is possible/likely that users would actually be able to type something like: [[Done]]
which would map to a State ID in the backend, so that if the State options were renamed, the formula would still work (and any change would be reflected in the formula).
Just re-visiting this as I came across another case where I have a relations hip to a parent with multiple single-selects for classification, that I wanted to summarise in a child in order to make a Board View less cluttered.
So you want the child entities to have a formula-generated field which takes the combination of multiple single-select in the parent?
And this field itself should behave like a single-select (be used for rows/columns etc.).
Did I understand correctly?
Yes, I want to be able to have Single-Select (or Multi-Select, Icon, etc.) as possible formula outcome and with the according value. The reason is that Boards only allow certain field types to be used for the row/column labels. Also, I clearly prefer structured data to free text, so if I can generate controlled dictionaries rather than free text, then that’s a plus.
Just a thought: Maybe in the formula editor I should be able to select the output type, rather than it be generated.
I don’t think there is any way to get an enum (single-select or multi-select) as the output of a formula, if you need the formula to take into account that the parent has multiple single-select fields.
Those multiple single-selects in the parent correspond to multiple (hidden) databases, and if it were possible to combine them into a single field, it would be something akin to supporting a polymorphic relation, which is not currently possible.
So I can set up a parent with two single select (A, B and 1, 2) an exploded single select (A1, A2, B1, B2) in the child entity and I could make 2 formulae on the parent that trigger whenever one of the parent single select changes to set the child single select based on their values… but I cannot assign single-select values…
I had understood your request as wanting the child to have a (multi-)select field that included choices A, B, 1 and 2, which it would inherit from the parent’s options.
But now I understand it to mean that the you want the child to have a (single-)select field that includes the 4 possible combinations.
I guess this is only possible using an automation, whereby the child single-select (with the 4 options pre-defined) is updated based on changes to the parent’s single-selects.
