Update condition for inheritance value hack
If the parent and child task have the same urgency the parent task also
needs the 0.01 extra urgency to be sorted above the child.
* Fix annotations in year 2038
Fixes#3050
* Ensure 32-bit systems work better after 2038
Without this patch, their 32-bit signed long int could overflow.
This patch was done while working on reproducible builds for openSUSE.
The data from the server is read via Task::parseJSON, not Task::parse.
This also reverts the tests for Task::parse, and adds new tests for this
specific issue.
getDOM takes an &Task that may be a reference to a dummy, or may be a
real task. The is_empty method replaces `task.data.size() == 0` as a
way to distinguish the two.
This edge case would happen if a user issued a following command
$ task 1 mod depends:
or
$ task 1 mod tags:
which would not perform as expected for tasks with non-empty depends /
tags attributes.
The problem under the hood is the fact that current synchronization
between 'tags" attribute and its constituent decomposed `tag_X`
attributes is performed in a way where the set of tags obtained from
`tag_X` attributes is taken as the source of truth.
If the legacy 'tags:' attribute was set to empty, the fixTags() method
would then restore its previous value from the `tag_X` attributes,
effectively leading to a no-op.
The same happens with dependencies. The fix here is to detect removal of
depends and tags attributes, and instead of setting the legacy
attributes to empty values, we iteratively remove all tags/dependencies.
Closes#2655.
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).
Each tag is stored as `tag_<tagname>: x`. The `x` is required because
empty attributes are treated as nonexistent.
For compatibility, the `tags` attribute is updated in sync with the
per-tag attributes. This compatibility support may be dropped in later
versions.
Note that synchronization _updates_ use JSON format, which does not
change with this patch, and thus no compatibility issues exist. The
synchronization _initialization_, however, uses FF4, meaning that a
sync server initialized from a version of `task` with this patch will
contain `tag_<tagname>` attributes, which will look like orphaned UDAs
to older versions. However, as updates to tasks are synchronized via
the sync server, the updates will not contain these attributes and they
will show as "deleted" in the `task info` display on the older version.
Aside from the noise in the `task info` output, this is harmless.
Since annotations are stored as a map, duplicate entry values lead to
data loss (i.e. annotations overriding each other on import). Perhaps
the choice of using a map internally should be reconsidered.
Closes#1938.
In bd4a7081, json-decoding of attribute values was introduced as a
workaround to properly handle blackslashes in description and
annotations (see TW-880).
However, this behaviour is no longer present with the new parser and
introduces its own suite of issues (i.e. see #2140).
Closes#2140.
