Just a complement to @Reinout_Decock’s response to explain how the formula works and a suggestion:
When running AddRow()
, in addition to adding a row in the target table, it also returns a reference to the added row.
So, in Reinout’s formula, the current row is modified, and the value
parameter receives the result of the AddRow()
action—which is the reference to the newly added row in the target table. I decided to explain this behavior because it’s not clearly mentioned in the formula documentation.
Using this formula in a button will create a row in the “Acceptance Criteria” table, but there are a few details to keep in mind:
The relation is set from the “Task” table side (as the formula modifies the current row and sets the reference), so the “Task” column in “Acceptance Criteria” won’t be populated. I believe the better approach is to define the relation from the “Acceptance Criteria” side, since the “Task” column would typically hold one reference to a task, while a single task can have multiple criteria. With the original formula, each time the button is pressed, the [Acceptance Criteria] column will be replaced with the new added row.
So, I recommend editing the formula to the following:
[Acceptance Criteria].AddRow(
[Acceptance Criteria].Task, thisRow
)
And in the “Acceptance Criteria” column, add a formula that computes the related rows from the [Acceptance Criteria] table.
[Acceptance Criteria].Filter(CurrentValue.Task = thisRow)
Second thing is, the “Criteria” column is likely to be created empty, and you’ll need to fill it in afterward.
Best regards
Arnhold