If I tag a project, I’d like to be able to view all its tasks as if they were tagged with that tag. Is it possible?
I may have tasks tagged directly as well as just an encompassing project. Id like to see both - tasks tagged and all project’s actions in one perspective.
If you tag a project, all new actions that you add to that project will have the tag(s) by default.
If you want the tag to be applied to all actions in the project, you would need to manually add the tag to any actions that were created before you tagged the project. The new bulk edit feature is handy for applying a tag to multiple items.
I hope this helps!
That was something I was afraid of. I’d like to use tags to quickly group projects actions. My use case is that I may have projects organized in folders by the area. During my weekly review I’d like to choose this weeks priorities by “flagging”=tagging these projects - without need to move them into any kind of this week folder.
I find this behaviour inconsistent. Flagging, defer/due dates get propagated down the hierarchy, while tags do not …
Thanx for your reply
May I ask you why you don’t use Flag for that purpose then?
I agree and I don’t think I can think of a good reasons to distinguish one case from the other 🤔 has anyone enquired about this?
Defer and due only overwrite those which are not within the correct time range or those not yet set. Tags are inherited by tasks created after the tag is added to the project, but doesn’t add to existing tasks - perhaps this is a holdover from how contexts worked before, but at the same time how would you differentiate between a tag that was just inherited from a project vs one that was added to a task and also happens to be a project tag? And how would you handle the removing of tags on tasks when they are removed from the project? While the current system may not be perfect it definitely works well in many ways.
I just can tell you that OF is totally inconsistent, messy and highly (!) limiting regarding inherited tags, due and defer dates. It limits the user in an unbeliavably way and is kind of following a philosophy made by the developers, thus giving their users less freedom in their workflow.
The best thing would be if OF would make more things OPTIONAL. So you can choose which behavior you want to have. This would make their App more powerful. And they should not worry that their Apps get too complicated for those hipster iPhone fast living youngsters, they can just go with the standard settings and the power users can change the App to their desire.
I had a similar problem with inherited defer dates, caused the CEO to write, that they have a different philosophy. SO DISAPPOINTING! (Look here: Stop Child tasks to inherit Due Date of Action Group)
Also I think its very manipulating if people who get sponsored by Omnigroup in what way ever, always get in into the discussion in this forum trying to defend why OF is like this and that, without being able to accept that there is problem. Always trying to tell you, that you are using the APP wrong and that you desire is kind of wrong.
I would always highly recommend to write to the OF-Support and ask for a feature. How they measure new functions to implement is by the amount people who write to the support. Just think of multiple tags. OF was against it until the pressure by the community was so big for a long time, they had to change their minds. And this is how it should be. The developers should listen to their users, not other way round.
I can only speak for myself (I’m not sponsored by Omni), but while it’s totally fair to criticize the app, this is a user forum, so I can only help people use the app as it is. I have no idea what features may change or come later, so I can only suggest how people might get the most from the app as it works right now. Only Omni can speak to how that might change, and so using their support channels (email moslty) is ideal.
As for the question of inheritance, the way I have always interpreted it is that projects are containers for actions that lead to a common outcome. If that container is due at a certain time, then the outcome must be due at that time, then the actions must all therefore be due at that time (or sooner).
If the container is deferred to a certain time, it means work on it cannot start until that time, so all actions must also be deferred until that time (or later).
If the container is flagged door importance, then its contained actions must also be important, and so are also flagged.
Tags, however, feel like they operate at the action level. If my project is to build a shed, I’ll probablay need to get materials, make calls, get quotes, acquire permits, etc., so not all of these things are things I would tag the same way, because I wouldn’t act on these things in the same contexts/priorities, etc. in the grand scheme of all my other actions. Personally, I avoid tagging projects, because I generally don’t want my actions inheriting.
Again, this is my workflow only, and how I see inheritance working. I am not defending anything, I am merely explaining how it works and how I use it. Who knows if/how things might change in future with the advent of tags.
ScottyJ
I find tagging projects messes up my perspectives, so I never do. I take the extra seconds to tag each action, or just add them through workflow and have that tag them automatically
I absolutely agree with you – you wouldn’t tag a project that had a vast number of very different tasks with one common tag. That makes absolutely no sense. It’s the same as with dates or flags: If there is no common denominator, don’t classify at project level.
But this is not what @Iljich is asking for. Only in cases where all project items share a common property, it would make sense to tag the project. For instance, you could tag your shed project with a „building“ tag which you could then use to easily find all building-related actions that you might want to delegate to somebody else.
That being said, if you (and @Janov) avoid tagging projects anyway, why not have those who do use it have it their way?
I don’t see much of an issue here: The same as with other inherited properties! Put them in italic font, maybe some dimmed color scheme, and only inherit if there is no explicit property set for the item itself. It has worked like that for the other properties for a long time now and I don’t see a reason to change it.
I’m not against anyone having anything other than how it is, but that’s not how the app works currently, so that would be a feature request for Omni.
ScottyJ
If I have a project that’s predominantly associated with a specific context, I typically apply that context to project itself, then specify a non-default context at the task level for exceptions.
For example, if I am remodeling the office at home, I would likely to tag the project as “@Home” rather than each of the work tasks individually. Then if I have a task such as “Go to store and buy paint,” I might tag that task as “@Errands”. This inheritance applies to existing (at least on MacOS, the comment from @rosemaryjayne leads me to believe this may not be the case any longer on iOS) and new tasks and saves me effort; why would anyone be opposed to that?
@dailyuser
Most people that rely on inheritance understand that it happens and find it advantageous. If you don’t find it useful, it would make sense to not use it, but I don’t know why you believe that turning off inheritance generally for one field is a logical enhancement. Again, you can just not add a due date to the project, or you can create a task titled “Wrap up project” and assign that the due date, leaving the project itself without a due date.
How does tagging a project mess up your perspectives? I don’t think I’ve seen that before, or at least not recognized it as an issue.
I’ve found my perspectives tend to show the projects as well once they are tagged, At least they were in OF2, now I can toggle the if not folder or project amd leave them out. So that is solved for me, but I still like to keep my perspectives on OF2 clean until the mac v3 is released.
I use flag to select actions that I want to do. In the use case I tried to describe I’d use tags to narrow options down … to reduce a list of actions before flagging.
It does not make sense to apply projects’ tags to new actions only … like, what is a meaningful use case for not applying project tags to previously created tasks? When I apply a tag to a project it should be valid for its entire content, not only new things in it … that’s at least what I am expecting.
and I’d say one thing is applying projects’ tags to tasks, the other is not being able to filter tasks based on all projects (or tasks group) attributes – I find it as a big ommision … (especially considering capability of unlimited hierarchies of subtasks)
Thank you for your comment on this. I see your point. I’ve for long been struggling with how to prioritize tasks in OF. As I have a lot of projects I needed to develop two step prioritization – 1st on a project level / Weekly. 2nd daily – tasks within these projects.
I like projects/tasks to be orginized into logical hierarchy – first is Area (folder), second something like bigger outcome (folder most often) and third mid-way deliverable (project). Now, I may have lots of deliverables on my plate and I’m looking for a flexible way how to pick those deliverables that I need to push forward next week. I can do that by moving them out of their folder to something like “This Week” folder, but that means moving things around a lot – so that would be my use case for tagging projects – to pick priorities within their native folder hierarchy.
Hi everyone, I just wanted to let you know that we have an open feature request for tag inheritance for existing actions that mirrors the same behavior for inherited flag statuses, and our Support team would be glad to add your +1 to that. Please feel free to drop us a line so we can add you to that request at omnifocus-ios@omnigroup.com. Thanks!
I just created a perspective that groups by context and see what you’re talking about now. Also made me realize that I’ve seen that in my Waiting and Agenda contexts (each of the sub-contexts appear below their tasks) and just never really thought anything of it. Thanks for the response.
I want you to cut back on the amount of coffee you drink… you’ll feel better.
