alanvardy / tod

An unofficial Todoist command line client written in Rust
MIT License
92 stars 9 forks source link

Named filters #592

Open pdxmph opened 6 months ago

pdxmph commented 6 months ago

When I add filters to task list (either interactively or as a -f option) I sometimes get errors:

method: GET
            url: /rest/v2/tasks/?filter=due_soon
            body: {}
            Error: Response { url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.todoist.com")), port: None, path: "/rest/v2/tasks/", query: Some("filter=due_soon"), fragment: None }, status: 400, headers: {"content-type": "text/plain; charset=utf-8", "content-length": "29", "connection": "keep-alive", "date": "Thu, 28 Dec 2023 18:34:03 GMT", "access-control-allow-credentials": "false", "access-control-allow-origin": "*", "referrer-policy": "strict-origin-when-cross-origin", "server": "gunicorn", "set-cookie": "csrf=xxx; Expires=Sun, 25-Dec-2033 18:34:03 GMT; Secure; Path=/; SameSite=None", "set-cookie": "tduser=v4.public.xxx; Domain=.todoist.com; Expires=Thu, 11-Jan-2024 18:34:03 GMT; Max-Age=1209600; Secure; HttpOnly; Path=/", "strict-transport-security": "max-age=31536000; includeSubDomains; preload", "vary": "Accept-Encoding", "x-cache": "Error from cloudfront", "via": "1.1 a94fec2514dd901c8ac91c6db99c3988.cloudfront.net (CloudFront)", "x-amz-cf-pop": "HIO50-C2", "x-amz-cf-id": "xxx"} }

I've verified the filter names. I've tried quoting in the command line, as well renaming them.

alanvardy commented 6 months ago

Thank you for the bug report! I'll investigate this as soon as possible.

alanvardy commented 6 months ago

This command is not for named filters, but instead for the filter text itself, i.e. image

I don't yet have support for pre-set filters (but will eventually). If you pass in the text that due_soon represents does it work for you?

alanvardy commented 6 months ago

If the above assumption is correct, do you have any suggestions on how I can improve the help text? image

rvbcldud commented 5 months ago

This really helped when I was figuring out how to find all of the lists associated with a specific filter. I think specifying "FILTER_STRING" is a good solution. However, on the Todoist website they call they "filter queries" which might be a bit more descriptive. Let me know what you think!

I would also love to see the ability to print out the tasks in my own created filters. Looking forward to that feature and would love to help where I can.

alanvardy commented 5 months ago

Hmmm... I like "FILTER_QUERY" better too, I'll make the change!

I would also love to see the ability to print out the tasks in my own created filters. Looking forward to that feature and would love to help where I can.

Which issue is this? Maybe I can prioritize it :smile:

rvbcldud commented 5 months ago

Awesome. Glad I could help. I would also say that since you would have both "PROJECT NAME" and "FILTER_QUERY" in the help message, maybe make a design decision on whether or not to use underscores.

I just looked and couldn't find the issue. It seems like this is the only one that mentions it. This issue is related but misunderstands the current functionality of filters in tod (only receives queries, not self-created filters). We could create a new issue that is more obvious that it is a feature that needs an implementation

stacksjb commented 5 months ago

I've wanted to add filter support too (https://github.com/alanvardy/tod/issues/374 was another issue where I'd like to have it).

However, I'm not sure the API supports predefined filters currently. My understanding of the "get tasks" API is that it only supports defined (provided with the query) filters. I've reached out to my API contacts to confirm. It might require multiple queries to get filters, then execute the get with the filter query.

rvbcldud commented 5 months ago

That would be a hindrance for sure. Let us know what you end up hearing!

stacksjb commented 5 months ago

I've confirmed with Todoist support the API only supports querying by filter query, not by Filter ID.

So implementing this would require that Query filters be stored locally, then query by those.

I wonder if a viable method might be to just add cli parameters for "Get filter" and "set filter", then just keep a global "Current filter" and set/add it to all API requests? I prefer to work through one filter at a time.

In either case, if we don't want to have to explicitly store the filter, we'd have to query it each time. So the only way to implement it as you describe would be to store locally and add logic to allow selecting a filter.

My use case is to be able to execute "Tod task next" with an existing filter.

stacksjb commented 5 months ago

I see a couple ways this could be implemented, but looking for suggestions/ideas:

1) Add logic for -f without anything specified, allow prompting to select predefined filter if a filter query is not specified (Ideally store the filters locally and add a config/setup option) 2) Make separate command line options for filters vs filter queries.

alanvardy commented 5 months ago

I've confirmed with Todoist support the API only supports querying by filter query, not by Filter ID.

Thank you!

I have an idea that kinda a mish-mash of the above, I would make a new subcommand called named_filter and use that for adding, removing and listing named filters. And that that named filter can be used anywhere the --filter option exists.

i.e.

Add a new named filter

tod named_filter add --name mytestfilter --filter "!subtask & today"

List named filters

tod named_filter list

Remove named filters

tod named_filter remove --name mytestfilter

And that the named filters can be used anywhere that the filter string is. What do you guys think?

stacksjb commented 5 months ago

Hmm - I like the above suggestion - how would you differentiate between named filters and filter strings?

Two other concerns: 1) It means I have to manage filters in two locations. I'd prefer to be able to import/select existing ones from Todoist. 2) I feel the command line options are/can quickly become too overloaded/bloated. I'd prefer to keep things like importing, adding, named_filters, etc in a separate menu, and then keep the use options for filters as they are.

stacksjb commented 3 months ago

The following API returns a user's filters (which we could then make some sort of import/setup/update method for):

curl --request POST 'https://todoist.com/api/v9/sync?sync_token=*&resource_types=[%22filters%22]' --header 'Authorization: Bearer $TOKEN'

stacksjb commented 1 month ago

This ties into one of my past workflows:

I have a series of filters that I have sorted into a daily list, so each day I start on list 1 (morning routine), then list 2 (daily review/planning), then 3 (deep work, coding, etc), then 4 (phone calls, personal items, errands), then 5 (home context), etc.

The filters are inclusive of exactly the tasks I'm looking for, and don't return anything I haven't prioritized or labeled for work or that is due in the future, then sorted based on due date. (a very common filter is & (no due date | due | overdue)

I have an excel spreadsheet list of each defined filter (filters 1-7) that I work through, depending on the context and day. In the past I had these filters saved as bookmarks and used Flowist (https://github.com/selfire1/todoist-focus-mode) to work through them, but now I have them saved in a config and use an app I threw together (to help me understand this one better 😆 (https://github.com/stacksjb/CLI_Shell_Command_Menu/) that I launch then that acts as a front layer to execute saved Tod filter and get next task commands.

I'd love be able to include named filters so I don't have to maintain them in multiple places - but this is lower priority since I can just duplicate them for the time being.