Bug #299

Can't use multiple project.hasnt:foo

Added by John Florian 291 days ago. Updated 185 days ago.

Status:Closed Start:10/11/2009
Priority:Normal Due date:
To:Paul Beckingham % Done:

100%
Category:core Spent time: 4.00 hours
Target version:1.9.0 - Kuwagata Estimated time:4.00 hours

Description

Only the last one on the command-line has any effect. It would be better if all were honored with a Boolean AND.

This should be true for all attribute selectors with a rejection connotation (hasnt, isnt). Conversely, for all attribute selectors with an inclusion connotation (is, has, startswith, endswith) should be honored with a Boolean OR.

I'm not sure what to suggest if there's a mixture of rejection and inclusion, however.

Also, don't forget we already have the ANDing with before and after to effect date ranges, which is essential.

Maybe it should assume a configurable default Boolean operator and allow new keywords to dictate command-line overrides?

History

Updated by Paul Beckingham 291 days ago

  • Status changed from New to Assigned
  • Target version set to 1.9.0 - Kuwagata

Good bug.

Currently all filter elements are combined with an AND, and there is no OR. This means that what you are attempting should have worked, and there's the bug.

Now, you also mention the inclusion/exclusion OR/AND thing, which is an interesting feature. I would like to hash this out properly, because I believe we have two things to consider:

1) task filters (task list pri:H pro:foo) are combined with AND because they are filters, and I think they need to stay that way. We have plans for including alternation, like this: "pri:H,L pro:foo" which would be evaluated as "(pri:H OR pri:L) AND pro:foo" But...
2) What you are describing is more along the lines of a SQL WHERE clause (perhaps an "advanced filter"?), and wouldn't it be nice to support that too. What if we had two methods, the first being the current AND-only filters, and the second more sophisticated, with AND, OR, parentheses for precedence, NOT etc?

Now I realize I'm talking into a bug report, and this should be a discussion in the forum.

Updated by Paul Beckingham 185 days ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100
  • Estimated time set to 4.00

Phew. Hours of thinking, minutes of typing.

Also available in: Atom PDF