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 On Sunday, 29 January 2017 14:01:20 UTC, John . Smith wrote: > > 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] > > > On 28 January 2017 at 15:10, pottster <[email protected] <javascript:>> > wrote: > >> 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. >> >> On Friday, 27 January 2017 16:21:04 UTC, Stéph wrote: >>> >>> 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. >>> >>> On Tuesday, 24 January 2017 20:46:27 UTC, John . Smith wrote: >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> On Tuesday, December 20, 2016 at 6:22:09 PM UTC, John . Smith wrote: >>>>> >>>>> >>>>> 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 >>>>> >>>> -- >> 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 >> [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/mylifeorganized/04387241-8bfe-4936-a0d4-238acb854565%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/12e804d3-cf25-4097-8189-cdd81168f390%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
