How to assign relations to child entity on creation?

Get Help
1

If a parent and child entity have the same relational field for example: Stories and Subtasks both have a relation to Products. Then when creating Subtasks on a Story card - how do I automatically assign the same Product to the Subtasks that are selected on the Story. Now when creating Subtasks, the Product field is not set at all.

1 Like
2

It sounds as though Subtasks should use a lookup to inherit the Product from the Story, rather than having a direct relation field to the Product.

1 Like
3

Thanks @Chr1sG. Could you explain how we should make this choice (between a relation and a lookup), in general?

4

You can use Lookup field in a Subtask and get project from Story, but only if the Subtask ALWAYS has Story.

If Subtask can live without Story, then lookup will not work. However, we are working on automations and for such scenarios it will be possible to create a rule to set Product automatically for every new Subtask you create.

1 Like
5

Can the Lookup capability become more complex?

6

As a general rule (for me anyway) a relation should exist when it is meaningful for the entities to be directly connected. Lookups are about inheriting or inferring information from an existing relation (and is therefore read-only).

So for a simple example, the classic hierarchy of Product → Epic → Feature requires that Features are related to an Epic, and Epics are related to a Product. There’s no reason why you would create a relationship from Feature to Product, since it can be ‘inherited’ from the Epic.
If you need to have a board where all Features are grouped according to their Product, then a lookup works fine. Although it won’t be possible to drag the Features from Product A to Product B, that’s actually quite logical, since a Feature needs to belong to an Epic - if you drag to Product B, which Epic should it belong to?

2 Likes
7

That makes sense. So how do I configure a sprint planning board with sprints as columns and projects as rows - that includes userStories grouped on project according to it´s “feautre product lookup”?

8

It depends on how your types are currently related.
Assuming that you have a hierarchy of Project → Feature → User stories and you also have Sprint → User stories
image
then you could try it like this:

image
image823×765 7.73 KB

image

Here’s the app:

9

I have features in a separate app with a relation to userStories. Otherwise I have the same setup.
The issue with this is that userStories that are not assigned to a project (only looked up by it’s parent) are not grouped with the associated project. Hence the need to automatically assign UserStories to the same project as it’s parent on creation. Or is there a way to group rows by lookup reference?
When planing sprint you intuitively what userStoris grouped by its corresponding projekt and doing this manly for every userStroy is time consuming.
One workaround I found its to assign UserStories on a Project list and configure filter to only show that project. Automation for this would be great to have.

Skärmavbild 2021-03-29 kl. 18.47.01
Skärmavbild 2021-03-29 kl. 18.47.012970×2148 699 KB

10

Yes.
You can use lookups as the row grouping (or column grouping for that matter) in just the same way as is possible with relations.

1 Like
11

That makes sense. So how do I configure a sprint planning board with sprints as columns and projects as rows - that includes userStories grouped on project according to it´s “feautre product lookup”?

12

Sorry, I don’t know what you mean by

13

Will automations help with this scenario:

Project     1:many   Product
Project     1:many   Task
Product  many:many   Task
  • My Products have a many:1 relation to a Project (a subset of a Project’s scope).
  • My Tasks also have a many:1 relation to a Project.
  • Tasks have a many:many relation to Product (maybe none).
    If a Task is related to any Product(s), they are all related to the same Project.

When I am editing a Product and I create a new Task there, the Task is related to this Product - great.

But the new Task does not “inherit” the Project relation from the Product, even though they both have a many:1 relation to Project - and in this scenario the Task must relate to the same Project as the Product.

Will Automations be able to help with this – i.e., to allow us to instruct Fibery to make this new Task inherit its Project relation from the Product that “fathered” it?

If not, the only way can I see to automate this relation is a webhook :disappointed_relieved:

14

It looks as though you would be best served by linking projects to products, and products to tasks, and just using a lookup to show the project for a given task and a lookup to show all tasks for a given project.

Can a task be linked to a project without being linked to a product?
I’m a bit confused, since you write

but you also write

What if a task is not linked to a product?

15

Yes, that’s the problem; my Tasks are fairly generic, and may not be related to any Product (though like Products they are always related to a Project).

So there will be situations where Tasks are created that have no Product relation with which to set their Project relation, but those can be dealt with some other way.

A more general explanation of the problem is that since a Task may be related to any number of Products (including zero), there is no “general” way for Fibery to infer what Project a Task should relate to, from the Products relation.

In theory a Task could be related to multiple Products that belong to different Projects (not that this should happen in practice). So I need something more complex than a simple relationship definition to automatically relate a Task to a particular Project.

I am hoping that Automations will allow me to create a rule like: “when a Task becomes related to a Product, and the Task is not already related to a Project, then inherit the Product’s Project relation.”

16

Absolutely this :slight_smile:

Anyway, I think this issue is not easily addressable currently, but I fully expect it to be easy with automations, assuming you can describe the rules to be applied.

For example

…what should happen if the Task is already related to a Project? Should linking to a Product be blocked?

I would hope that relations filters might be able to prevent that from happening.

1 Like
17

This particular case is just about saving the user from having to manually relate a newly created Task to a Project, when there is enough info available that this could be automated (i.e. the Task is already related to a Product, so its Project can be inherited/inferred).

If a Task already has a Project, this situation doesn’t apply. I would hope that Automations will be flexible enough to allow the outcome to be tailored to the specifics of each situation – so, I don’t want a “general” answer to your question; I want the flexibility to write an “intelligent” Automation that can determine on a case-by-case basis what is the correct answer.

18

I’m sure that automations will support what you want to achieve.
In the meantime, I wonder if you would consider an alternative: action buttons
You could have a button in Projects (called ‘Create task’) that spawns a new Task and auto links it to that Project, and a similar button for Products, which links it to the Product and the parent Project.

1 Like
19

Good solution, though I am concerned about Action buttons proliferating everywhere, for every special case – visual clutter, and a nightmare to maintain.

Thus I asked earlier for:

1 Like
20

Am I missing something, or is this whole thing not caused due to limitations in the visualization? In other words, what i see here is:

  1. The view can’t do what the user expects it to
  2. Based on the limitations of the view, more relations have to be added to try to get the view to work as expected
  3. Automation of some kind is desired to create these additional relations added only to make the view work

There are a couple considerations about this:

  • We don’t know at this point for sure that automation will solve this particular problem until we see its own limitations
  • Adding all these additional relations just to get a view to work correctly, complicates the entity view since fields can’t be hidden yet
  • Should these additional relations need to exist in the first place for the view?

Personally, I see the root cause of this as being limitations that exist with the smart folders and hierarchical lists. If the user is forced into jumping through hoops with additional relations, automation, etc. something else is wrong.

I have run into this same issue where you end up adding all these lookup relations to try to get these views to work, which really makes a mess of the entity and creates a bunch of confusing relationships on it.

1 Like