Support creating, fetching, and deleting reminders

[kquinsland]

Enhancement description

I would like to be able to set geo based reminders for tasks via API. It looks like this is only possible via the sync based API but the python SDK for that is EOL.

The problem it solves

Feature Parity with the API that's no longer got a supported SDK.

Alternatives

Use case / screenshots

When getting close to $theGroceryStore, pop up a get milk tasks in my phone's notification area.

Additional information

https://www.todoist.com/help/articles/use-location-reminders-in-todoist-uGcwH2AJ6

[goncalossilva]

Makes sense! Reminders are absent from the SDK, including time-based reminders.

This is very similar to #103, including the reason it's not available just yet—only being available via the /sync endpoint. We need to add basic CRUD support first in the API first, and then it becomes trivial to add them to the SDK. /cc @PotHix

[kquinsland]

Makes sense! Reminders are absent from the SDK, including time-based reminders.

This is very similar to #103, including the reason it's not available just yet—only being available via the /sync endpoint. We need to add basic CRUD support first in the API first, and then it becomes trivial to add them to the SDK. /cc @PotHix

Is there any chance y'all bring back the python SDK for sync? The majority of my use (80%+) is similar to the guy in #103 - bulk actions based on rules. I am not hitting rate limits, but just barely.

A lot of my use case boils down to "get all 1100+ tasks, iterate through the list and if $task meets $criteria, do_changes()" which - as far as I can tell - results in a ton of requests to the API.
It would be better if the old "get all tasks cached locally, do the needful, sync(), go back to sleep" workflow was possible using non EOL code.

[goncalossilva]

I'm afraid we're not planning to bring the old SDK back.

We've also merged our APIs into just one (with /sync being just one endpoint on it), and we're planning to make more significant changes to the way we sync later this year / early next year. Not relying on /sync is not such a bad idea, considering the rest of the API should remain relatively stable for the foreseeable future. It'll save you rework.

Beyond manually implemenitng our /sync API workflow, I wonder if a use case like that can be served in a simpler and more stateless way. The filter parameter of our get tasks API is powerful and might encode part of that $criteria logic you seek. 🤔

Regardless of the above, there should definitely be proper endpoints for filters and reminders.

[kquinsland]

Looking forward to those sync related changes being public :).

The filter parameter of our get tasks API is powerful and might encode part of that $criteria logic you seek. 🤔

Not in this case; $criteria is a set of different things that get chained together.
One link in the chain might be interested in all tasks where the description or title matches $someRegex or $anotherRegex. If there's a match on $anotherRegex, the task should be moved to $someSection unless it's already tagged with $someTag or exists in $someSetOfSpecialProjects. Regardless of which regex matched, all tasks get $someLabel

I could maybe use server-side (?) filters but get_tasks() does not support compound filters...

The second link in that chain is going to "start" by querying for tasks that are in $someSection which - without a local cache - means a round trip to the server for each task, for each link in the chain.

Several chains are executed on a regular-ish interval to triage any tasks that have been added from other sources.