Summary
pipefy_pipe_relation is managed but not readable. Connections between pipes are frequently created in the UI by whoever owns the downstream process, so a config that needs to reference one, or to check how it is mapped, cannot see it.
Part of #89.
What the API allows
resource_pipe_relation.go:274 reads through the parent pipe:
query GetPipeRelations_tf($pipeId:ID!){ pipe(id:$pipeId){ childrenRelations{ ... } } }
No singular relation query, so the shape is a list keyed on the parent pipe.
Proposed
pipefy_pipe_relations, taking pipe_id and returning the relations with piperelationgql.Selection: id, name, the can* and mustBeDone/mustExist flags, auto_fill_field_enabled, parent and child (each resolving to a Pipe or Table id), and own_field_maps with field_id, input_mode, value.
Decide whether to expose parent relations as well. The read above only covers childrenRelations, which is the relations where the given pipe is the parent. A config on the other side of a connection cares about the inverse. Either add a second attribute backed by the pipe's parent relations, or take a direction argument.
own_field_maps is worth surfacing rather than skipping. It is the part users get wrong, and being able to read the current mapping is most of the value of this data source.
Notes
The parent and child selections use inline fragments on Pipe and Table, so both come back as a plain id with no type discriminator in the current selection. If the data source is meant to tell a user whether the other side is a pipe or a table, it needs __typename added, which the resource does not select today.
Follow #88 for how this talks to the API.
Summary
pipefy_pipe_relationis managed but not readable. Connections between pipes are frequently created in the UI by whoever owns the downstream process, so a config that needs to reference one, or to check how it is mapped, cannot see it.Part of #89.
What the API allows
resource_pipe_relation.go:274reads through the parent pipe:No singular relation query, so the shape is a list keyed on the parent pipe.
Proposed
pipefy_pipe_relations, takingpipe_idand returning the relations withpiperelationgql.Selection:id,name, thecan*andmustBeDone/mustExistflags,auto_fill_field_enabled,parentandchild(each resolving to a Pipe or Table id), andown_field_mapswithfield_id,input_mode,value.Decide whether to expose parent relations as well. The read above only covers
childrenRelations, which is the relations where the given pipe is the parent. A config on the other side of a connection cares about the inverse. Either add a second attribute backed by the pipe's parent relations, or take a direction argument.own_field_mapsis worth surfacing rather than skipping. It is the part users get wrong, and being able to read the current mapping is most of the value of this data source.Notes
The
parentandchildselections use inline fragments on Pipe and Table, so both come back as a plain id with no type discriminator in the current selection. If the data source is meant to tell a user whether the other side is a pipe or a table, it needs__typenameadded, which the resource does not select today.Follow #88 for how this talks to the API.