Open claremacrae opened 1 year ago
the mapping between "status" and "status type" sparks a lot of discussion and lots of requests for additional types to query from, but I believe searching for status character would be the better priority. For all my use cases and status types overlaps and confusion, it would solve all problems in a very clean way
rough example: if "delayed" is actually done depends on context. do I look at current planning? all done, as "delayed" is moved to next period. Do I look at an "all tasks" list? "delayed" means "not done yet"
search for [d] and [x] is super easy to understand and there's no need to predict additional configuration
Hi @xenontechs, thanks for the input. Much appreciated.
search for [d] and [x] is super easy to understand and there's no need to predict additional configuration
That sounds appealing in theory, and I agree that searches on the character would work well.
But as soon as users get used to not setting up their custom statuses, then Tasks will not know their intention when they toggle one of these unknown status characters. Was the character TODO, IN_PROGRESS, DONE, CANCELLED etc?
So I suspect your reasoning might trade one set of user support load for another - for me and for users.
Tasks will not know their intention when they toggle one of these unknown status characters
maybe I miss something with this extra layer of abstraction, but we have this configuration (screenshot) already, I guess it needs a default setting for toggling unknown. From there, with search based on symbol, there is no direct need for status types and Tasks knowing user intentions.
I can totally see the status types as more of a grouping function, so when a user sets up a bunch of tasks, they can (as is practically already) define them as TODO to quickly search for them using that keyword, or set default behaviors (any type TODO when toggled gets the first type of DONE unless otherwise specified)
as is today, there is just no fine-tuning queries outside of a very limited set of types. I keep hitting this brick wall and apart from it being an easy entry, I don't understand why it is there at all, why this can't be freely assigned
Tasks will not know their intention when they toggle one of these unknown status characters
maybe I miss something with this extra layer of abstraction, but we have this configuration (screenshot) already, I guess it needs a default setting for toggling unknown. From there, with search based on symbol, there is no direct need for status types and Tasks knowing user intentions.
Yes, the bit you missed is the bits marked in red:
When a user clicks on a checkbox, and tasks modifies the line, it needs to know what to do, about adding or removing Done dates, and about recurrence.
See:
Which is why I said:
But as soon as users get used to not setting up their custom statuses, then Tasks will not know their intention when they toggle one of these unknown status characters. Was the character TODO, IN_PROGRESS, DONE, CANCELLED etc?
So I suspect your reasoning might trade one set of user support load for another - for me and for users.
This is why it matters that users properly configure their custom statuses.
I do still intend to implement this, when I have time and it gets to the top of my list.
My point is just that anything along the lines of 'then users won't need to configure their custom statuses' is not a good argument in its favour.
I realised that a lot of the implementation work for this is equivalent to that in StatusTypeField.ts.
It's not quite the same, but still helpful.
The status symbol search would need to be case-sensitive, and would need a special case to parse and display space
characters.
It is now possible to search for tasks with particular status symbol characters...
See the several examples Status Symbol in the Filter docs:
Here is a snapshot of the current content:
I'll leave this open until either:
⚠️ Please check that this feature request hasn't been suggested before.
🔖 Feature description
Provide a way to search for tasks with a particular symbol, such as
[?]
.I already added
status.name
andstatus.type
searches in 1.24.0.For brevity, I think it would be helpful to be able to search for the actual symbol character.
✔️ Solution
I'm thinking something like this:
It would need to be case-sensitive, unlike pretty much every other Tasks filter, as
A
anda
are different symbols.I think it would probably be good to allow multiple values
❓ Alternatives
status.name
searches📝 Additional Context
No response