AUTOMATION!
Vidas
Vidas
Marco Kollster: I will merge automations request with a bigger item about the same idea so we have more upvotes. Also, I wanted to emphasize that if you need some "default" values when creating items in rows - you can set "default" template for that row. Template can contain color/tag/description or other properties. At least partially this could solve your need.
S
Sting
Another use case for automation: automatically close items that haven't been updated for a specified period of time. Closed items could be automatically archived after they have been closed for a certain period of time. These two automations would significantly declutter the workspace views.
Vidas
Sting: very valid point. Clutter is a big issue if not tackled continously.
Vidas
Martynas Gailius we are actually in consideration state for this concept currently. Can you share specific examples how would you use it?
Martynas Gailius
Vidas: Certainly. We work with items, that have many child items. Each parent item goes through many stages, according to which of its child items have been completed. We represent these stages as statuses. It would be great that when a child item has been completed, the status of the parent item would be changed accordingly. Now we have to do it manually, and sometimes some items are left with an unchanged status, even though their child items have been completed.
Another example could be when a child item is completed the parent item would be tagged 'unasigned', so it would be clearly visible, that an item is idle and needs to be assigned.
Some items that we work with don't have a deadline, but the ones that do, need to stand out among other items. Now we just manually tag them, but it would be great that when a certain child item is added (e.g. product release) the parent item would be tagged as having a deadline.
We would probably use even more automations, but for now these are the main ones that come to mind.
R
Richard
Vidas We've recently started using TH and basically use it the same way as Martynas Gailius; a parent for each project + child items for each stage. This means we always change the status twice. First by marking a child as completed, second by changing the parent status.
In an ideal situation, we could configure it so checking a child would change the parent status as well as the other way around – moving the parent with child items to another column marks a child completed.
But, even only one of the two would be a big win and we would adjust our way of working accordingly..
Vidas
Richard thank you for emphasized the scenario. We are collecting feedback here. It will take some time when we are ready with open capacity and we have strong understanding which use cases to focus on first, since the option spectrum very broad.