Grouping by a column when dealing with sub-tasks

Get Help
1

Hi all,

I am pretty new to Fibery, but I love it! The one obstacle for me to expand my usage of it even further is the need for us to heavily rely on the Task / Sub-Task model.

As far as I understood from previous posts in this forum, an easy way to implement sub-tasks in Fibery would be the following. Go to the Task database, add a new column, choose “New Filed”, then “Relation to…” and then choose the Task database itself. This way we can easily create a Parent and a Child columns.

Then, we can go to the table view area and group tasks by parent. However, the key limitation that I think this setup / workaround has is that, to best of my knowledge, you then cannot group tasks by any other column. This is no small limitation. For example, in our case, our tasks have a column “Area”, and fi we add the “Parent” and “Child” approach, we absolutely need to have tasks displayed, in the task view, grouped by “Area”, and then grouping their child (sub)tasks.

Is there a way to achieve that? I cannot seem to find one, given the limitation of one group-by per level.

2

If Area is a db, then you can choose Area as the first level in your view hierarchy, and then choose Tasks as the second level (which still allows you to have Tasks grouped by Parent).

3

@Chr1sG With the new layout for grouping, it might be an idea to allow to “Add Level” above the database hierarchy as well. Then you don’t need to remake the database hierarchy if you want to add a level to the top.

4

I have also come across this limitation a couple times, and both times were not with relations. The first is a view with tasks-subtasks (wanting to group via the state field). The second is a view with documents (and subdocuments, again wishing we could group by the state field). We’re making due with just showing and sorting by the state field, which has been fine, but it’s not quite the UX we’re going for.

There might be an issue if a sub task/document has a different state than its parent. In this case, I would expect the subentity to stay grouped under its parent entity.