Filtering project:someday broken

[FRebbel]

Hi,

To report a bug...

• What command(s) did you run?

task add project:someday foo

• What did you expect to happen?

List of tasks related to project:someday

ID Project Description
 1 someday foo
 2 ....

• What actually happened?

task project:someday
[task next ( project:someday )]
'bar' is not a valid date in the 'Y-M-D' format.

task projects

Project Tasks
bar         1
someday     1

I recently upgraded taskwarrior from Version 2.5.1 --> 2.5.3. I like to order some of my projects/ideas under the project someday
but now the filtering is broken.

BTW thanks for this awesome app :).

[indev29]

I tried to reproduce the issue and that's what I came up with:

task add project:someday 1
Created task 1.

task add project:bar 2
Created task 2.

task add due:bar 3
'bar' is not a valid date in the 'Y-M-D' format.

task project:someday
'bar' is not a valid date in the 'Y-M-D' format.

Apparently, if you accidentally set invalid due value, project:someday filter breaks forever (2.5.3, head of 2.6.0 aswell). Besides that, project:someday works fine for me.

[FRebbel]

Hi indev29,

but I didn't set any due date for task 2.

task
[task next]

ID Age   Project Description Urg
 1 22h   someday foo            1
 2 21h   bar     test           1

2 tasks

I would say this is desired behaviour:

task add due:bar 3
'bar' is not a valid date in the 'Y-M-D' format.

[indev29]

but I didn't set any due date for task 2.

My bad, for some reason it did work for me yesterday until I tried a due date.

[indev29]

someday is parsed as date, as well as shorter versions like some.

CLI2::prepareFilter desugarFilterAttributes
  _original_args
    ./task ( status:pending limit:page ) next project:someday
  _args
  ...
    dom canonical='project' modifier='' raw='project' FILTER 
    op raw='=' FILTER 
    date raw='someday' FILTER 

I'd like to fix this. Should there be a check here to avoid calling CLI2::lexExpression for project or should it be fixed another way @tbabej?

std::vector<A2> values = ((name == "project") ? {{value, Lexer::Type::identifier}} : lexExpression(value));

[indev29]

This also may be related to #2206

[tbabej]

I'm not sure.. while that certainly seems like it would fix things, I believe it would prevent resolving DOM references like:

task add project:3.proj task with same project as task id 3

(which currently does not work)

That said, we could implement something along those lines (not just tertiary operator, as I suspect other attribute names and possibly custom defined UDAs would need this logic too) and eventually revert this once DOM expressions are supported.