No exp/gold for recurring tasks

[cecilyperez]

When I found this I migrated my dailies to Todoist for stuff like every other day functionality, and I've noticed I don't get any exp or gold for recurring tasks - it just changes the due date instead of completing it and adding a new one.

[crookedneighbor]

@Kusold I bet it's because Todoist never marks a repeating task as checked, which is what determines whether or not the up event gets sent to Habit.

[crookedneighbor]

@Kusold this wouldn't be a perfect solution, but we could check the date_string parameter, and if it contained keywords that would trigger a repeating event, such as "every", "ev" and "after" and if the due date has changed since then, trigger the up event.

The only downside I can see to this is if someone changes the due date manually, they'll get credit for completing it.

[cecilyperez]

@crookedneighbor I will definitely say I've done that today as the equivalent of graying out dailies. It's not a huge deal for me (I'm going to continue using it as is), but thought I'd make sure you guys knew/for others that do care more.

[kusold]

I captured some API responses from Todoist. I'm going to first get every day repeating tasks working. It should be pretty similar to what @crookedneighbor suggested where the date_string is checked. I'm not seeing anything in the API response that will let us see if a daily is postponed or completed.

For non everyday tasks, we can check to see if the due date is less than X number of days away to determine if it was postponed or completed.

[crookedneighbor]

@Kusold @cecilyperez

I have a branch with my proposed solution.

The one idiosyncrasy I've found is that part of the update task event in Habit's API is to mark the task as checked and move it to the completed tab. This means that every time the repeating task is checked in Todoist, it will be marked as completed in Habit until the next time the task is checked or edited in Todoist, which will cause the task to reappear in the remaining tab.

Further, if you click the "Delete Completed" button, then a habit gets generated with the id of the original task as the name.

[crookedneighbor]

@Kusold Good idea tackling the repeating tasks integration. You could use a regex to do the matching. This probably isn't the best regex for it, but it would do the job:

/\b(ev(ery)?|after)\b.([1-7])?(.)?\bday(s)?\b/i

I don't think I'm following how you're going to handle the non-everyday tasks.

How will you handle date strings like these:

every 9 days
ev 26 Jun
every 3 months starting tuesday

[crookedneighbor]

Actually, that regex wouldn't take into account strings like: Every wednesday

[kusold]

This may be a little opinionated, but I think that if a task is repeating in Todoist, then we should either create it as a "Daily" (unless it is repeated more on a larger than once a week scale, in which case a todo item is appropriate I think). HabitRPG allows you to select certain days to repeat on. Unfortunately this will require a little logic on our side. I think this may work around the issue you are seeing @crookedneighbor.

[crookedneighbor]

Okay, I see what you mean now. When you said, Non-Everyday tasks, you meant dailies that don't repeat everyday. I thought you meant repeating tasks that repeat on an irregular basis.

Yes, getting the daily integration to work will solve the two problems I mentioned for recurring events that reoccur at least once a week. It won't solve it for the irregular recurring events (IE, ev 2 months)

For reference, as you figure out the logic of determining the todos, here's the list of examples for how to do repeating event strings from Todoist's docs, I've separated them into tasks that would become Dailies and tasks that would become Todos.

Dailies every day every mon, fri at 20:00 ev day at 1pm ev weekday every day at 14:30 starting 1 Jan

Todos ev 3 days starting next monday ev 7 (every 7th day of the month) ev 7 may every 13 may every last day every 2nd monday

The trickiest part will be the last daily, since it's a repeating event that reoccurs within 7 days, but doesn't start occurring until after a certain date. Maybe not sync it to habit at all until after the start date (or, easier, start syncing on the first due date)?

The other tricky one is the ev 3 days one, since it wouldn't cleanly line up as a daily, since it's repeating every 3 days, not on specific days of the week.

In general though, it seems like the first order of business will be to determine if the event repeats at all, this regex should do that: /\bev(ery)?|after\b/i. The second would be to determine if it qualifies as a daily, and if it does, to determine what days it should be active.

If it doesn't qualify as a daily, would it be smart to remove it from the sync history file so that it continually gets added to HabitRPG as a new Todo every time it gets completed? This would make it so the todo only disappears until the next sync, rather than the next time the task is completed, and if the completed tasks get cleared, a new habit wouldn't be formed.

There's also the "until" element we'd have to deal with, ie: every 3 days until oct 21 is valid. Maybe delete the task after its end date?

[crookedneighbor]

I was wrong about "until", though it's valid in the date_string field, it doesn't actually do anything in Todoist.

[crookedneighbor]

I figured out a possible solution for this.

We could make it so that everything with a date string that indicates that it repeats a Daily that has no days set as active days. That way, when a task is marked as completed on Todoist, it'll still mark it as complete on HabitRPG and gain exp and gold from it.

Not sure what it'll do to the tracking stats from that task, but it will work, I believe.

May need to retool it once this goes into production: https://github.com/HabitRPG/habitrpg/issues/4173

@Kusold What do you think?

[crookedneighbor]

Note: Looks like you can't convert a task of type 'todo' to type 'daily', so there'd have to be some kind of migration in place to delete tasks that started out as todos and a repeating date pattern was added after it was created.