How to assign relations to child entity on creation?

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

Can the Lookup capability become more complex?

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

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”?

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

Here’s the app:

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.

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

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”?

Sorry, I don’t know what you mean by

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:

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?

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.”

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

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.

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

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

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

That’s a very fair point. Creating fields solely to enable a specific configuration of a group view (table, list, board etc) will lead to field proliferation which is frustrating and clutters up when not needed.
Having said that, I thought perhaps that Matt’s question related to seeing Project information when viewing a single Task (as opposed to enabling configuration of a group view) and in this case, the visible field is the piece of info you need.
My bad.

It will be possible to create such rule at some point. I hope in 1-2 months.

1 Like

This is in progress already, there will be Actions button for every Type and it will be possible to define custom Actions for Types via UI (code will still be available for complex cases).

1 Like