It would be useful to have the possibility to delete the entity (f.ex. Feature) with all it’s sub-levels or have an option to move them to another entity (of the same level maybe).
Yes, chiming in, I can see a need for both the idea of cascading deletes, and also cascading deactivations, so that board filtering will work effectively. As you use the app over time, you will have a lot of sets of multilevel data, and while you might not want to delete it, there should be a way to flag it somehow.
Client A - Active? [√] |__Contract - Active? [√] |__SOW - Active? [√] |__SOW - Active? [√] Client B - Active? [x] |__Contract - Active? [x] |__SOW - Active? [x] |__SOW - Active? [x]
But there are also times that, even if you mark an Employee as having left (inactive), you want the entities they created to live on…:
Employee - Active? [x] |__Wiki-Page - Active? [√] |__Attachment - Active? [√]
Would it be possible to define relationships so that an entity’s existence is dependent upon another related entity? For example, if a Project contains many Tasks, when the Project is deleted, all Tasks that were associated with the Project are deleted too. In other words, a Task cannot have a life of its own, so effectively, the Project relationship is a mandatory field for a Task.
Yeah, that’s another thing I’m missing from Clickup. I think that can be easier accomplished via automations. Automations will be a huge feature in Fibery and I think it should be prioritized.
This will be done with Automations. However, don’t expect it in the next 3 months. I hope we will start working on automations in the Fall.
Good to know, and your transparency about the roadmap is appreciated.
Glad to say, that this is already possible with Automations already - but in terms of 1 step hierarchy.
So, if you have Project - with one click you delete Project and all the linked Tasks.
You can’t (for now at least): Delete Project, linked Tasks and linked Subtasks - that improvement is in the backlog although
Isn’t it the case that you can automate deletion of all children, grandchildren, great grandchildren etc. through unlimited hierarchy, so long as all the relationships are 1:n (parent:child)?
Namely, by setting a rule for each child type that if count of parents = 0 then delete entity…
It is nice idea. I checked that and it works. Please find below the example on how nested collections can be cleaned.
Let’s assume we have three levels on hierarchy.
Create rule for subtask on changes related to it’s task: “Remove subtask if it’s task is empty”
Create rule for task on changes related to it’s story: “Remove task if it’s story is empty”
It means that every time when story will be deleted then story’s tasks will be updated with empty story
and then these tasks with empty story will be deleted with the defined second rule. Subtasks will be updated with empty task and then will be deleted with the first rule since subtasks have empty task field.