Add filter support

[stacksjb]

Essentially all the work I do in Todoist to actually complete tasks resolves around Filters and Labels, not Projects. This is the biggest limiter to me fully using Tod to effectively complete work (instead of processing and scheduling)

All of my "tod" workflows to complete items resolve around filters (i.e. see #374)

For example, I may have a project for each of my 5 work clients, but I have one filter for items tagged as @Computer and @Work, or @Computer and each #Client1 #Client2 #Client 3 etc

Thinking about how filters fit into the workflow, I think it would be best to duplicate the "tod project" functions that are applicable (import, process, prioritize, schedule) into a seperate "tod filter" structure, as opposed to trying to add filters into the "tod project" structure, which is not as applicable, since filters aren't edited, modified, or changed within Tod - they're primarily static once created. They're used to view and act on tasks - you don't add tasks directly to filters.

@alanvardy @titoOdUA Do you utilize Filters at all within Todoist? I heavily rely on them.

[stacksjb]

An additional option to return only "is_favorite", or duplicating local vs remote config (like is done with projects currently) would be ideal.

[titoOdUA]

Yeah, I do use filters and labels. For now, I am focused to create some simple "reports" that can be used to just show the list of tasks, not interactive. After it, I think I would like to explore the ability to add support for labels and filters. Reports/filters can be a part of one system/submodule.

As for the way to iterate with filters I would like to see something a little more sophisticated than the current flow to process tasks one by one. Because the filter can show me some groups of tasks. But I can be interested in a specific one within that group, and I don't like the idea to process all of them to just finally find the one that I need.

Again, it can be done separately before or after the implementation of the filters themselves. I don't know how flexible the Todoist API is in regard to filters. Does it provide the ability to construct filters on the fly or are you allowed to work only with previously created filters/must create and save filters and only after that you can use them.

[stacksjb]

Again, it can be done separately before or after the implementation of the filters themselves. I don't know how flexible the Todoist API is in regard to filters. Does it provide the ability to construct filters on the fly or are you allowed to work only with previously created filters/must create and save filters and only after that you can use them.

When interacting with "Filters", you can only interact with those that are created/exist previously (though you could create/interact with the filters specifically), and you get a list of the filters and their values returned.

You don't actually interact with Filtered queries directly as a task list; rather you include them as part of your API call. (i.e. I could have a task present under multiple filters). A "Filter" is just a predefined query, and you can execute/search those against the API to return the matching tasks in any method. So what you actually do is execute the defined filter against your query as part of your api call (?filter=<urlencoded filter query goes here)

An example from my workflow: I have a filter called "Mornings! Start of day" with a filter query of "@Morn & (due today | overdue | no due date)"

To get tasks that match that filter, I query the REST api with: /rest/v2/tasks?filter=%40Morn+%26+%28due+today+%7C+overdue+%7C+no+due+date%29

Querying the filters endpoint would just give me the stored filters & values, which I would have to re-use against the API.

So in short, filters are just a query string you actually execute against the API, and don't have to be stored remotely (if they were stored locally in config array, they could be copied, imported, or synched from there)

[alanvardy]

Definitely in favour of adding tod filter and adding functionality one at a time, but for the classic "list items by filter" I think that would belong under tod task list as a flag i.e.

tod task list --filter "due today"

because it lines up with the --project flag that is on there

And then everything else, including adding/using remote filters or processing based on a filter would be under tod filter process etc.

What do you guys think?

[stacksjb]

Completely agree - love the "task list --filter" idea

My question is whether someone wants to act on Projects or Filters - For me, I would prefer to act on Filters for task completion (and projects for processing) - for example, I'd love to be able to select "Tod task list" and select a filter instead of a project.

[alanvardy]

I was thinking about this a little more, and realized... why not both?

So if someone types in tod task list without any options it will first get them to select from

> project
  filter

And then they can select the project or filter after that. I personally use projects as my contexts like a savage, and I think this solution could work for both of us.

[stacksjb]

I really like this route!

(And if they type "tod task list filter" or "tod task list project" (or whatever the exact format that makes sense), the option can be already/automatically selected?)

Side note, I really, really love the powerful flexiblity of how the CLI is structured on tod - great work there! I love that I can interact with it as an interactive program for working on things in general, but then I can also easily define specific parameters for frequent tasks and execute them in one line - and everywhere in between.

(Put simply, it's not only a parameterized script or a full interactive program - I can run it as both. So powerful!)

[stacksjb]

Quick note - for filter workflow, the "empty" workflow is not going to be applicable.

But the remainder to complete, get next, label, etc workflows will apply the same.

[alanvardy]

Going to start on this soon @stacksjb

• [x] Display labels on formatted tasks
• [x] Add --project and --filter to tod task list
• [x] Add --project and --filter to tod task next
• [x] Add tod filter label with --filter argument and --labels that narrows the label options
• [x] Add tod filter schedule with --filter argument
• [x] Add tod filter prioritize with --filter argument
• [x] Add tod filter process with --filter argument

[alanvardy]

Out now on release 0.5.4, please open up issues if I might have forgotten anything!