Get Flags to 'inherit'

[John . Smith]

Hi 

If new tasks were able to inherit the Flag of their parent task - in the same way that Contexts do that would really help me. 

Any takers?

J

[Stéph]

That's one of the things I'd like to set up as optional behaviours (ie I'd like to be able to select whether new items inherit flags, contexts, start and due dates or whether these parameters get set to a default value).

Stéphane

[Roberto Penzo]

+1

[John . Smith]

Yes, Steph's suggestion would be ideal, although more complex and so more costly to develop.

If we can't have that, I am wondering if anyone actually object if new tasks were made to inherit the flag of their parent?

J

[Stéph]

I wouldn't want that - It would completely mess up my system. I'm using flags for some things (identifying roles and goals) specifically because they don't inherit, but categories do.

[pottster]

I agree with Steph. I would not support this change. The way I use flags would be made unworkable if flags were inherited. That's what contexts are for.

[Smith, John]

Nope, I don't get it. Surely Context-tags are for CONTEXTS!  i.e. To me, roughly speaking, a "context" would be 

- physically where you are executing the task   AND/OR

- what mood or energy level it will require you to be in    AND/OR

- what software would be involved. 

And because a task can only have one Flag at a time they are not appropriate for allocating multiple such "contexts" at once. 

To get clear, I am only talking about inheriting the value of a flat at the time of creation of the task, yes? 

i.e. The "child" task would be "born" with the flag value of it's parent. Thereafter it could be freely changed.

Would inheriting roles and being part of goals really be such a bad thing? Maybe yes.

Separately, I need a field that can be used to control one's overall attitude to whether or not it should be done. i.e. its "actionable status" if you will. (e.g. Active/Next, Someday-maybe, Waiting, Archive, Later, Travel-List etc). I don't like using Context-tags for what is really actionable status because it clutters up my real contexts. 

TBH, I still don't understand how other users manage to control their action statuses. I tried using folders but when you have large volumes of data moving between folders gets way too messy. "Hide branch in to-do" is useful but that is binary with only two values - on and off. So you can only have 2 statuses. (Active and Someday).

OK so if we do understand each other, would you folks still object if the user was allowed to control the inheritance at birth of flags somewhere within MLO's Settings?

J

PS Fwiw, what I really want is a new, completely separate field for status, which would be inherited at the time of a task's creation. Or better it might even FULLY inherit. i.e. a Task's value as far as filtering is concerned would be:

A) it's own value if set, but if not 

B) it would take on the value of it's most recent parent that did have a value set.
In this way you could move an entire project tree in an out of say Someday-Maybe simply by changing one value at the root of the project tree.

But I doubt MLO developers would have the stomach for such a large change.  [sigh]

--
You received this message because you are subscribed to a topic in the Google Groups "MyLifeOrganized" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mylifeorganized/AbKtleSaT7A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mylifeorganized+unsubscribe@googlegroups.com.
To post to this group, send email to mylifeorganized@googlegroups.com.
Visit this group at https://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/04387241-8bfe-4936-a0d4-238acb854565%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stéph]

No problem with having the option of flags inheriting, as long as I can choose not to inherit (same as I'd like to be able to do with contexts).

In reply to your aside about actionable status - I have contexts for "?Waiting For" and "Someday" and "-Superseded". For me, this is fine as I only have a list of 16 contexts. I agree that folders wouldn't work for this as it would involve moving items around each time their status changes - Also, because I use folder and list hierarchy to associate tasks with projects and goals. Overall I have

Stéphane

To unsubscribe from this group and all its topics, send an email to mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.

[David Timpe]

I'd like to be able to turn off all inheritance. For me this is always unique and the first thing I do when I create a subtask is to clear the dates and the context. Inheriting flags would create more waste for me.

Contexts, dates, and dependence controls whether a task can be done or not for me. I don't worry about energy level and I don't capture things I don't intend to do except for in the someday/maybe folder which isn't getting done until the task is moved, given dates and a context at which point it becomes active when it should.

[Lasse Pedersen]

Like others have said, it would have to be an option, not fixed functionality.

The way I use flags at the moment, mandatory inheriting would screw it up.

That being said, the reason I use flags is that they are mutually exclusive - which contexts are not.

If there was a way to make a group of subcontexts mutually exclusive, I would use those instead of flags in my current use case.