I’m finally creating my first database/workflow in Fibery. How can I implement subtasks so that:
- All subtasks can have subtasks
- Subtasks can have multiple parents
(My projects are often interrelated and share subtasks.)
If you use a “many-to-many” relation for subtasks instead of a “many-to-one”, that should allow you to make it sufficiently confusing, as you’ll sacrifice any sense of hierarchy in the relations - i.e., no parent/child distinction any more, since all both ends of M2M relations are equal.
Allowing multiple parents to link to a single child while maintaining a hierarchical parent/child distinction would require a new Type/DB to for the links themselves: technically possible, but not pretty and probably too much of of a PITA to be worthwhile.
you’ll sacrifice any sense of hierarchy in the relations - i.e., no parent/child distinction any more
Allowing multiple parents to link to a single child while maintaining a hierarchical parent/child distinction would require a new Type/DB to for the links themselves:
I may just be unfamiliar with the Fibery DB, but I’d like to insert a task or subtask within the hierarchy of another task, where it would show relative to the current nesting:
If I create a task called
Walk the Dog with subtasks
Get on shoes
Open DoorGo outside
Close Door
In another task I want to be able to include it as a subtask like:
Go To Store
Make Grocery List
Bring Grocery Bags
Go OutsideClose Door
So both hierarchies are preserved, they just share a task so that checking it off on one marks it done on the other as well.
Edit: Added image to original post I meant to upload the first time.
If every task/subtask can have only one direct parent, then you can use a many-to-one relation. This type of relation has two fields: “Children” (a collection), and “Parent” (a single entity, not a collection), giving you a tree structure.
But in your illustration the “shared subtask” has two parents, so you can’t use a many-to-one relation to model that - it would have to be many-to-many relation as I described, and the problem there is that you only get a single collection field, instead of one for the parents and another for the children - so no more hierarchy.
You can certainly use a many-to-many relation (call it “Related Tasks”), but you would sacrifice the hierarchical/tree structure entirely, and Fibery would not be able to treat it as a tree, due to the possibility of loops in the graph of related entities.
You could have two, separate many-to-one relations – “Parent Tasks” and “Child Tasks” – but you would have to do some scripting to make this work, and I’m not sure Fibery could visualize such a graph the way you expect.
1 Like
That’s disappointing…Fibery’s thing is supposed to be linking information and building your own structure, but it can’t show a task/subtask in another task? No one here has tasks that show up in multiple projects or overlap? Can I at least reference it as a subtask somehow? Maybe something like ClickUp, where the task/subtask is shared but it still “remains” in the original task?
If the same task or subtask is required for multiple tasks or projects, how would you handle that?
You can do the same by defining another entity called Shared Task and allow that to be part of multiple Tasks or Subtasks (many-to-many).
But, as @Matt_Blais pointed out though, this will easily get confusing.
The challenge here is that you seem to want a hierarchy that allows for infinite nesting. If you want to enforce a hierarchy (tree), you require one-to-many (parent to children) setups.
Without that you will have a graph, which does exactly what you want but you will not have a hierarchical tree. Has nothing to do with the tool and all to do with the structures of graphs and trees. 
Lastly, my suggestion to your dilemma is to only have a Task database with many-to-many relationship for dependencies on other tasks. Then each task can display if it is dependent on other tasks or if it’s blocking others.
You may be able to build circular blocking references, but that’ll be on you as a user to avoid (you could probably write a JS automation that regularly checks for such blocking circles).
Hope that helps.
I keep some information in TheBrain, and Fibery was attractive because it seemed to have similar features but actually has task management features. TheBrain is a many-to-many DB, but it can still display hierarchy. If items overlap in what they’re mapped to in one of the linear views, it chooses one element to display them under and shows a line that represents a link to the other parents.
However, rather than a database that branches out (/up/down) from a single starting node like TheBrain, Top-Level Tasks could be “discrete” within their Space, and thus have multiple trees with hierarchy in parallel. If a Top-Level Task was linked to another parent within the space, it would simply cease to be a Top-Level task. Subtasks could be defined in one task, and anything added to the shared subtask would obviously change everywhere (as it’s the same entity).
I did a poor job of explaining that part, but in that way a hierarchy can be preserved even with tasks sharing subtasks. That’s possible in terms of DB structure, is it something that’s possible to create in Fibery?
1 Like
So the one thing that Fibery does not really handle is recursion. So, for example, you can have a List or a Table View that can unfold into related items, but what they cannot handle is unfolding more layers of the same entity, so a tree of tasks.
I suspect that this is a design choice for performance, as it minimises the risk of infinite loops.
Our setup has Tasks with Predecessors and Successors and inside the Task I can see those, all I cannot do is have a tree view where I can unfold such a tree…
So it looks like this:
Just to be nice and clear; Fibery can easily handle having a relationship where a Task can have multiple Parent tasks (and a Parent can have multiple Children).
You would simply create a many-to-many self-relation, and you can name the two fields as ‘Parent’ and ‘Children’ to distinguish them.
You could even use the recently-released ‘Display as Compact List’ option to make them even more distinct.
It’s not actually correct that
and infinite nesting is not the problem. Both one-to-many and many-to-many relations allow a functionally infinite number of levels (and both allow circular relations, e.g. A → B → C → A 
).
However, List view and Table view only support showing a hierarchy of self-relations for one-to-many relations (to generate a tree of Tasks).
As explained (sort of) above, this is partly because a many-to-many relation doesn’t have a ‘direction’.
Just because you name your (m:m) relations as Parents and Children, Fibery doesn’t understand if you mean this:
or this:
and there are loads of challenges that come with trying to represent a structure which is not a ‘directed tree’ but more like an ‘undirected graph’
1 Like
Thanks for the in depth explanation Chris. I do see the issues you raised. Forgive me if I’m being dense/inexperienced, but could you simply organize it similarly to the diagram here, with Top Tasks having no parents (and not being able to have parents)? Perhaps barring adding a subtask with any identical node higher up the same tree? (I’m actually not too worried about infinite recursion from a task management standpoint, but I see how this layout could otherwise end up with infinite trees [A → B → C → A → B → C → A …etc.])
And if nothing like that is possible, am I perhaps missing a simple solution? If need be I suppose I can perhaps reference a task within the task tree, but it shouldn’t necessarily be as a block?
It is certainly possible to imagine possible visualisations of m:m self-relations, including like the one you propose, but as it stands, it’s quite technically challenging to achieve using the current Fibery architecture in a way that would be reliable/robust and wouldn’t consume a load of resources.
So it just hasn’t been implemented, sorry.
Might you find that displaying Tasks on a whiteboard is sufficient?
Were a solution that simple sufficient, I would have found a solution long before I found Fibery. I don’t suppose having a fixed number of subtasks (instead of recursive/infinite) would make any difference?
So just to make sure I’m clear, there’s no (reasonable) way to show a subtask from a separate task in a different task? Even if it’s just a reference?
I can’t make a promise, but the simplest solution might be to wait a week or two
4 Likes
I can’t make a promise, but the simplest solution might be to wait a week or two
@Chr1sG you have no idea how excited my data nerd heart is right now! I’ve had to spend at least 100 hours by now looking for/demoing databases and project managers to date. Fibery’s selling point on the rigidness of other “flexible” PM/DB software’s is spot-on–I tend to think non-linearly, and it’s a little embarrassing how difficult it can be to fit myself into strictly linear systems. (The demo video showing how easy it was to bi or multi-directional link info inside Fibery was what convinced me to put the time in to learn it.)
If/when it happens I assume it’ll be in the release/changelog, so I’ll keep an eye out!
1 Like
can leak something Chris? new feature ?
With the recent release, you will be able to select many-to-many relations recursively at root and inner levels. Please, try the feature and provide your feedback: does it work for your case or not? It could be experimental, but it’s a very niche feature, so we released it without going through our lab 
3 Likes
I super appreciate that! Can I ask for a tip on how to implement it? I’m having a little trouble figuring it out. 
Set up a many to many self relation, and name the two fields appropriately, e.g. Parents and Children.
Then, in table view, choose to show Tasks and then group by Parents
1 Like