The intent here is to make similar the implementations of
getIntervalsById and getTracked, since they are both gathering a
collection of intervals from the database, but they are just using a
different criteria for which ones to pull.
This also eliminates the use of std::deque.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Eliminates extra noise in the debug output. I.e. from #422 the original
report contained:
>> 2021-05.data: Deleted inc 20210511T161243Z # "TRACKER-6145"
>> 2021-05.data: Added inc 20210511T161243Z # "TRACKER-6145"
Which isn't doing anything.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
This fixes an error where the latest interval, a non-synthetic interval,
is added to the synthetic array (and marked synthetic) if flatten() is
otherwise not able to convert it to a group of synthetic intervals.
When modify was attempting to edit this interval, it would fail since
synthetic intervals should not be written to the database unless the
database is being flattened and timewarrior believed the interval to be
modified was synthetic.
Closes#422
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
- Filter shall be taken as is, not changed
- If there is a problem, the functions consuming the filter have to be adapted, not the filter
Signed-off-by: Thomas Lauf <thomas.lauf@tngtech.com>
This fixes the bug where, when filtering by tags, the interval IDs are not
preserved when not using any tags in the filter. Notice below how when
filtering with tag1, the two intervals are @4 and @5 instead of @1 and @5 like
they should be:
$ timew summ :ids
Wk Date Day ID Tags Start End Time Total
W9 2020-02-29 Sat @5 tag1 15:28:31 15:28:33 0:00:02
@4 tag2 15:28:33 15:28:35 0:00:02
@3 tag3 15:28:35 15:28:36 0:00:01
@2 tag4 15:28:36 15:28:48 0:00:12
@1 tag1 15:28:48 - 0:02:25 0:02:42
0:02:42
$ timew summ tag1 :ids
Wk Date Day ID Tags Start End Time Total
W9 2020-02-29 Sat @5 tag1 15:28:31 15:28:33 0:00:02
@4 tag1 15:28:48 - 0:02:28 0:02:30
0:02:30
This fixes a bug introduced in 86bb1465e8.
Closes issue #293 (thanks sskras)
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
getIntervalsByIds will be used by commands that are loading complete database
currently when they really want a few intervals that the user specified by ID.
Related to issue #245
The getUntracked, called as part of the `timew gaps` command, is
normally looking at a relatively recent interval. We do not want to take
the performance hit of loading the entire database into memory when
processing this command.
Related to issue #245
This does not appear to be necessary anymore given that the database lines are
generated from intervals and are all well formed. Any open interval *should* be
at the end of the database.
Related to issue #245.
