scottquach/Canvas-Assignments-Transfer-For-Todoist

RFE: Add labels and priority

Closed this issue · 8 comments

I have added labels and priority to my latest branch , as well as reworked the initial config (with a single config variable and a separate initial configuration loop), so if users want to configure those parameters they can (otherwise they'll be set to defaults). I'd love it if you'd take a look and let me know any thoughts before I submit a PR.

However, I have one issue I'd love some help on since you tackled a similar problem elsewhere in the code.

I added the "todoist_task_labels" dict with which you can submit the task with the appropriate labels (or none; it will still submit successfully). However, you need to submit with label ids, which most end users likely don't know.

So, while it works if I manually add the label IDs to the config.json, most users are going to want to enter the label names as part of the initial config setup, which we then would need to either a) query and match up with existing labels, and/or b) create them or throw an error if they don't exist. (This is basically the same process as you do in the code for the initial projects).

They're easy to pull with "labels = todoist_api.state['labels']", but not sure about how best to match them up.

This is an important feature for me and others who use custom filters, because otherwise I have to create filters for each and every project, whereas I group them all under common labels (such as "school").

It may be best to have a setup step that essentially creates a mapping of friendly label names to label ids. And then having that verify on every run for changes/deletion of tags vs. the local config copy

@scottquach @stacksjb I've implemented a keyword-based priority system on the main branch of my fork.
This dictionary defines the keywords for each priority level:

    keywords = {
        4: ['exam', 'test', 'midterm', 'final'],
        3: ['project', 'paper', 'quiz', 'homework', 'discussion'],
        2: ['reading', 'assignment']
    }

Otherwise priority is 1 (normal).
I also made it set the priority to highest if the duedate is within 3 days of current time.
However I haven't made it configurable yet, it's just defined inside the code.

When I finish it up and add a way to configure it, I could raise a PR.

Wow this is amazing! Interested to see how it all works once it's complete 🧐

@andreicozma1 that looks amazing, look forward to seeing how you do it.

For me the most important thing is to just label tasks (since I use a filter to show all my todos), and a higher priority in general (static is generally fine) - but I do really like the idea of higher priority if it's due within the next week (I tend to only run my sync script ~weekly).

Thank you! For the labeling I was thinking of two different possibilities too, 1. where the user can choose to manually label individually selected tasks, and 2. where labels are automatically assigned based on key words.
I am thinking to use a similar mechanism as the priority keyword matching, and that result would be used as a "default label" initially. Then the user would be prompted if they want to accept the automatically chosen labels or manually tweak them with a selection screen (I like to use the 'pick' library).

Now, the 3rd idea would be a little bit more work, but besides these two options I was thinking of an additional approach based on semantic search (possibly using OpenAI's GPT API). This would essentially be able to semantically pick one of the existing labels the user has based on the semantics of the task title (such as pre-existing labeled tasks). However this would be an "experimental" feature that the user would need to also input their OpenAI API key, but perhaps it has potential.

For my use purposes, I just want to label all tasks with specified label, such as "Classwork". But I do really like the idea of automatic label keyword matching similar to above.

For my use purposes, I just want to label all tasks with specified label, such as "Classwork". But I do really like the idea of automatic label keyword matching similar to above.

Cool! I'll keep that in mind for implementation, I want to cover most possible use-cases so that's helpful to know!

I added basic functionality for this to my fork.