GothenburgBitFactory
[TW-1849] UUID displayed instead of ID with custom data.location
Jan Stolarek on 2016-08-31T17:28:54Z says:
I say:
{code}
[killy(at)GLaDOS : ~] t add "Foo"
Created task 21.
[killy(at)GLaDOS : ~] t 21 done
Completed task fd6146d9 'Foo'.
Completed 1 task.
{code}
Notice that the message displayed when a task is completed does not report task ID, but instead uses its UUID. I have tried commenting out various sections of my configuration file and concluded that the single line responsible for this behaviour is my custom setting of data.location.
Migrated metadata:
Created: 2016-08-31T17:28:54Z
Modified: 2017-10-12T03:01:28Z
Jan Stolarek on 2016-09-01T09:51:19Z says:
I tried symlinking .task to point to my directory with task data in hope to work around this problem. Surprisingly this also triggers the bug.
Jan Stolarek on 2016-09-01T11:27:56Z says:
Another bit of information is that mod command correctly displays task ID:
{code} [killy(at)GLaDOS : ~] t add "Foo" Created task 21. [killy(at)GLaDOS : ~] t 21 mod "Bar" Modifying task 21 'Bar'. Modified 1 task. {code}
Jan Stolarek on 2016-09-02T11:36:10Z says:
I investigated source code for the stable release a little bit. It looks like the bug is related to adding tasks to backlog. In CmdDone, if I change line 103 from:
{code} context.tdb2.modify (task); {code}
to
{code} context.tdb2.modify (task, false); {code}
Then the problem disappears. Obviously, this is not a proper fix but hopefully might give developers some hint about the nature of the problem.
Jan Stolarek on 2016-09-02T12:15:44Z says:
Still more investigation. It turns out that the bug is somehow related to on-modidy hook provided by timewarrior. If I disable that hook then task IDs are displayed correctly. I have no idea whether the problem is caused by incorrect handling of hooks within taskwarrior or incorrect implementation of hook script.
Paul Beckingham on 2016-09-02T22:19:22Z says:
I feel this is related to a change we made recently, but have not investigated yet. Good work.