Insert into SmartList behavior with an OR
gmealer says:
If I create the following smartlist, things work fine:
list:Actions AND tag:_next AND due:never
If I insert into that, things go into Actions and get auto-assigned the _next tag.
However, if I create:
list:Actions AND tag:_next AND (due:never OR dueBefore:tomorrow)
to consolidate dated and undated tags, insertion now throws away everything and just inserts defaults. This causes the newly inserted task to drop out of the list immediately, before i can edit.
Seems to me there's no reason for this, and I'm wondering if I'm doing something wrong. They're all ANDS at the top level, and the only thing it can't figure out the due OR. However, consistent behavior would be to insert the list and tag, since those are unambiguous.
So, questions:
A) Am I doing something wrong?
B) Is there a way to edit fields before it has a chance to drop out of the smartlist?
Right now, I'm having to separate dated from undated to have a 'Next" list I can enter into, but I'd really like to consolidate them into a single dashboard.
list:Actions AND tag:_next AND due:never
If I insert into that, things go into Actions and get auto-assigned the _next tag.
However, if I create:
list:Actions AND tag:_next AND (due:never OR dueBefore:tomorrow)
to consolidate dated and undated tags, insertion now throws away everything and just inserts defaults. This causes the newly inserted task to drop out of the list immediately, before i can edit.
Seems to me there's no reason for this, and I'm wondering if I'm doing something wrong. They're all ANDS at the top level, and the only thing it can't figure out the due OR. However, consistent behavior would be to insert the list and tag, since those are unambiguous.
So, questions:
A) Am I doing something wrong?
B) Is there a way to edit fields before it has a chance to drop out of the smartlist?
Right now, I'm having to separate dated from undated to have a 'Next" list I can enter into, but I'd really like to consolidate them into a single dashboard.
zabeans says:
Your SmartList requires all tasks on that list to have 3 properties - a specific list, a specific tag and a specific due date. If a task is missing one of these, it will not appear on your list.
The FAQ's state:
Note: Properties are only inherited where the Smart List is unambiguous. If your Smart List looks for tasks that are tagged apples OR oranges, the new task won't inherit either tag. However, if your Smart List is for tasks tagged apples AND oranges, the new task will be tagged with both of these tags.
So the task you insert in the list cannot be automatically tagged with "due:never or "dueBefore:tomorrow" because of the OR. So now the task is missing one of the requirements for the SmartList, so that's why it gets dropped.
Sorry if that was obvious, maybe what you're really asking is why it doesn't keep the first 2 properties even if it can't determine the 3rd. I guess that's a question for the RTM staff...but I would think that could cause more problems for some people. What if you had a SmartList with 10 different properties, and half of them were (___OR___) statements. If it got tagged(for lack of a better word, since it wont be just tags) with the unambiguous statements and pushed out of the SmartList for not having all the properties, I would think it would be even more confusing to sort out later what properties were applied and which ones weren't, rather than just not applying any properties at all. I hope that makes sense.
Using 2 lists seems to be the best solution to me.
The FAQ's state:
Note: Properties are only inherited where the Smart List is unambiguous. If your Smart List looks for tasks that are tagged apples OR oranges, the new task won't inherit either tag. However, if your Smart List is for tasks tagged apples AND oranges, the new task will be tagged with both of these tags.
So the task you insert in the list cannot be automatically tagged with "due:never or "dueBefore:tomorrow" because of the OR. So now the task is missing one of the requirements for the SmartList, so that's why it gets dropped.
Sorry if that was obvious, maybe what you're really asking is why it doesn't keep the first 2 properties even if it can't determine the 3rd. I guess that's a question for the RTM staff...but I would think that could cause more problems for some people. What if you had a SmartList with 10 different properties, and half of them were (___OR___) statements. If it got tagged(for lack of a better word, since it wont be just tags) with the unambiguous statements and pushed out of the SmartList for not having all the properties, I would think it would be even more confusing to sort out later what properties were applied and which ones weren't, rather than just not applying any properties at all. I hope that makes sense.
Using 2 lists seems to be the best solution to me.
gmealer says:
Yeah, looks like that's where it'll have to go.
I bet enough people need a clause like:
(dueBefore:tomorrow OR due:never)
i.e. all tasks without an assigned date after today
that they could put that into its own query function that won't mess up the tag inheritance on the rest.
That is the basic query you need to have a single list that doesn't show you tasks dated in the future. That lets you use the due date as a "start date".
I should suggest that over in ideas.
Thanks for the help!
I bet enough people need a clause like:
(dueBefore:tomorrow OR due:never)
i.e. all tasks without an assigned date after today
that they could put that into its own query function that won't mess up the tag inheritance on the rest.
That is the basic query you need to have a single list that doesn't show you tasks dated in the future. That lets you use the due date as a "start date".
I should suggest that over in ideas.
Thanks for the help!
zabeans says:
What about
"not dueAfter:today"
"not dueAfter:today"
Well, this one has already been solved. You need a check smart list: www.rememberthemilk.com/forums/tips/3700/
In order for un-ambigouos smart lists, you can't use OR or NOT.
In order for un-ambigouos smart lists, you can't use OR or NOT.
gmealer says:
raijan,
Thanks! I eventually muddled to a variation on that solution on my own (mine's called *Fix), so good to see I followed established footsteps!
Thanks! I eventually muddled to a variation on that solution on my own (mine's called *Fix), so good to see I followed established footsteps!