This adds a note to the man page to properly escape filters containing
spaces. It also fixes the unittests to reflect this.
One of the unittests contained an alternative syntax as discussed in
TW-1479 (#1505). It has been extracted into its own unittest and marked
as an expected failure because it is currently not supported.
The Undo command broke in 48dff11 when the `onModify` hook got added to
its execution in order to fix#2213. The reason for it begin broke is
that a Task object is created in an unsafe manner because the `prior`
task may be empty.
Catching this case fixes the bug.
I verified locally that this avoids skipping all of the
faketime-dependent unittests. The Travis CI logs will have to be
investigated for all of the other docker images on which distros we may
need to apply a similar fix.
This is an attempt at updating all docker configurations by simply
replacing the `python` packages with `python3`. The Travis CI will let
us know if this works.
This change was not included in the previous commit because the sed
command I used included the `/usr/bin/env` path to ensure I don't
replace any occurences of the word `python` which I did not wish to
replace.
This commit updates all tests to enforce the Python3 executable. This is
necessary because the `assertRegex` function we use was renamed to this
name only in Python 3.2 [1]
For reference:
s;/usr/bin/env python;/usr/bin/env python3;g
[1]: https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRegex
$ task 0000000d-000a-0000-0000-000000000000 export
Cannot subtract strings
$ task 0000000d-0000-0000-0000-000000000000 export
The expression could not be evaluated.
Due to not accounting for the leading "P", getNextRecurrence would always return the same datetime, breaking all generic "PnM" periods and leading to an infinite loop in generateDueDates.
The test was failing because it expected "Created task 1"
but it saw "Created task 0a436fd8-7f06-4168-a66d-bbc940498af9".
Instead, the new code looks at the description of task 1.
This fixes a regression was introduced in
4e80d5d5fd.
Currently, if a user (with default configuration) adds a completed or
deleted task, they do not get a confirmation message ("Created task
..."). This is due to the fact that:
a) new-uuid is not set by default
b) new-id is set by default, but only prints message if the added task
is in pending or waiting state
Make sure to print a message containing UUID reference if the newly
added task is in completed or deleted state.
The test was failing on my machine on fresh checkout. It failed because
somehow both new-id and new-uuid verbosity were set during the test, so
TW defaulted to printing out uuid, which did not match the assertion.
Test fixed by explicitly setting verbosity to new-id.
Per the beginning of the man page, the summary line should give the default value. This isn't the case in a few places, so I changed them. (No guarantees I found them all.)
Previously, multiline string UDAs were not preserved when editing
a task via 'task X edit'. String UDAs are now JSON encoded/decoded
during the edit cycle to allow preservation of multiline
