TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's
`Task` type more cleanly. It also introduces the idea of gathering lists
of operations and "committing" them to a replica.
A consequence of this change is that TaskChampion no longer
automatically maintains dependency information, so Taskwarrior must do
so, with its `TDB2::dependency_sync` method. This method does a very
similar thing to what TaskChampion had been doing, so this is a shift of
responsibility but not a major performance difference.
Cxx is .. not great. It is missing a lot of useful things that make a
general-purpose bridge impractical:
- no support for trait objects
- no support for `Option<T>` (https://github.com/dtolnay/cxx/issues/87)
- no support for `Vec<Box<..>>`
As a result, some creativity is required in writing the bridge, for
example returning a `Vec<OptionTaskData>` from `all_task_data` to allow
individual `TaskData` values to be "taken" from the vector.
That said, Cxx is the current state-of-the-art, and does a good job of
ensuring memory safety, at the cost of some slightly awkward APIs.
Subsequent work can remove the "TDB2" layer and allow commands and other
parts of Taskwarrior to interface directly with the `Replica`.
Taskwarrior uses "expire" to refer to deletion of tasks past their
"until" date, so let's use `purge` to link this semantically to the
`task purge` command.
Consistently exclude WAITING tasks from reports which filter by status
If I understand correctly, the virtual status "waiting" is deprecated.
This is why some reports include the explicit "-WAITING" filter even
though it is not necessary: The idea is that being explicit will be
needed in the future when the "waiting" status is removed.
But I noticed that some reports do not include the "-WAITING" filter, so
I added it to all reports that filter by status.
* Add support for cloud sync, specifically GCP
This adds generic support for sync to cloud services, with specific
spuport for GCP. Adding others -- so long as they support a
compare-and-set operation -- should be comparatively straightforward.
The cloud support includes cleanup of unnecessary data, and should keep
total space usage roughly proportional to the number of tasks.
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
In #3118 @ryneeverett mentioned that "key" suggests that this is a
secret, when in truth it's just a user identifier. So "ID" is a better
word for it than "key".
This removes use of gnutls and the TLS implementation, which is no
longer needed (task synchronization is handled via Taskchampion, which
uses `reqwest`, which handles TLS via other Rust dependencies). This
incidentally removes the following config options:
* `debug.tls`
* `taskd.ca`
* `taskd.certificate`
* `taskd.ciphers`
* `taskd.credentials`
* `taskd.key`
* `taskd.server`
* `taskd.trust`
This is a corner case bug, when user has both old-style and new-style
context defined, where new-style is defined as empty string, the
old-style will (incorrectly) take precedence.
Closes#2629.
This also drops support for the transitional `json.depends.array`
configuration value, which has not been necessary since ~2016.
As with tags, dependencies are stored in both a "combined",
comma-separated format (for compatibility) and in an
attribute-per-dependency format (for the future).
This patch allows e.g. due.by:tomorrow that includes all of tomorrow,
because it uses less than or equal to, rather than just less than, like
'before' modifier does. This allows matching the last second of the day
when filtering by "due.by:eod", and more generally allows date filters
with an inclusive end-interval specification.
Closes#2536
Simlifies by offloading portion of the logic into the singleton Context
class (which has nothing to do with the task context per se, just a
implementation singleton).
