Taskwarrior: [TW-1944] adding new tasks in context

Created on 14 Feb 2018  路  14Comments  路  Source: GothenburgBitFactory/taskwarrior

_Jean-Francois Joly on 2017-04-15T12:59:06Z says:_

Could tasks added in context have the proper tags added implicitly, in such a way that the tasks would show up as part of the current context without having to add them manually?

As an example, if I am in the +work context and I add a task, I would not have to specify +work every time.

enhancement wont fix

Most helpful comment

Could I suggest that for a given context named "foo", a configuration item named "context.foo.default" be added, which can specify the default attributes that should be added to any new task created while in the context "foo" ? E.g.:
context.work = status:pending and (project:work or +work)
context.work.default = +work due:now priority:H

All 14 comments

Migrated metadata:

Created: 2017-04-15T12:59:06Z
Modified: 2018-01-12T12:26:18Z

_Paul Beckingham on 2017-07-30T11:07:48Z says:_

Good suggestion, thank you.

_Tomas Babej on 2018-01-12T12:05:53Z says:_

Let me just note that this was discussed when designing this feature. The reason why this wasn't implemented is that it would have to be implemented only for simple contexts, because contexts like:

"project:Home or project:Chores"

does not have deterministic mapping to a given set of task attributes (should new task belong to project Home or to project Chores?).

Not readily solvable.

Could I suggest that for a given context named "foo", a configuration item named "context.foo.default" be added, which can specify the default attributes that should be added to any new task created while in the context "foo" ? E.g.:
context.work = status:pending and (project:work or +work)
context.work.default = +work due:now priority:H

That's quite workable, actually. Thanks.

The issue has been closed, but is this still beeing considered? I had a similar idea and it would spare me a ton of time on my daily usage.

No, closed issues are not worked on, but they remain in the system, for potential reopening. Things change...

It's a matter of providing good use cases that cannot be solved externally, combined with available time and funding.

@pbeckingham
That would be great to have this feature. I have lots of tasks and I use contexts a lot.
I often do task add bla and then task x modify +work / project:work

Having some defaults applied to new tasks while in context would be great, otherwise I can easily loose tasks if I don't tag them immediately.

With some mentoring/handholding I can draft a PR

@ngortheone : as for me, I try to regularily review tasks without projects task pro: to identify these "lost" tasks and bring them back to the system :)

yes, that makes sense and I do that too. Regardless, I'd still love to have this feature

@pbeckingham - someone suggested a way to bind default add settings to a context so that add settings per context would always be deterministic, but this issue wasn't re-opened to be considered. It's unclear on this issue whether that's because another issue encapsulating that workable suggestion has been made, because this issue was re-considered and decided 'never to be worked on', or ...?

I, for one, would still find this greatly valuable. Although it isn't ideal, it's a reality that different projects have different flow and conventions, especially when integrating work tasks into the mix.
While simple cases (that go beyond switching the default.project) can be covered by user written shell aliases and functions, this bandaid breaks down super fast. It also means in addition to remembering these bandaid alternatives, I have to remember which ones are useful as defaults for each context.

A way to switch between different add command defaults that context could (or not) set a default to force that add default to be active would be great. It would allow those who have need of often used add command configurations/metadata to use them whenever (easily making TW way more efficient out of the box for people taking advantage of its rich metadata), override the active one with a context's default, or opt out completely and never set a context add default or general add defaults.

Extremely hacky workaround if your context filter is usable as a modifier (no conditionals, etc):

t_addtocontext ()
{ 
    task add $(task context show|cut -d \' -f 4) $@
}

Example:

$ task context show
Context 'autoProvision' with filter 'pro:work +autoProvision +lso' is currently applied.

$ t_addtocontext provisioning delay
Created task 6.
The project 'work' has changed.  Project 'work' is 90% complete (5 of 51 tasks remaining).

$ task

ID Age   Project Tag               Description           Urg 
 4 10min work    autoProvision lso watch daemonset        1.9
 5 2min  work    autoProvision lso defaulting volumeMode  1.9
 6 3s    work    autoProvision lso provisioning delay     1.9

3 tasks

This is now considered for 2.6.0.

Was this page helpful?
0 / 5 - 0 ratings