While poking around in the code, I noticed that HabitRPG has updated it's API-version and deprecated version 1. Your tool is built for V1.

Adding a task still works, but the extra fields you use for identifying already added tasks are no longer present.

Do you have any idea on how to match existing/already synced tasks against a running sync?

I would be glad to help/revive this project at least to the point where it's working for me.

See http://cweagans.net/blog/2013/4/12/anydo-unofficial-api

I'm trying to install this, and not getting anywhere - it appears to work, but when I go to use it I just get an error.

Screenshot of what I'm getting:

Now I've got authentication working for both APIs and can pull tasks from Habit.

Copy-pasting the plan I typed to myself on IRC:

[16:44:45] <wizonesolutions> RTM AUTHENTICATION WORKING wooooooo
[16:45:05] <wizonesolutions> now some client work, then hopefully I can get a really basic sync working
[16:45:31] <wizonesolutions> goal 1 is just to add all tasks to Habit that don't already exist and don't even parse the Habit todos yet.
[16:45:48] <wizonesolutions> then add in some logic to not double-add
[16:46:05] <wizonesolutions> then logic to delete ones deleted on the RTM side
[16:46:42] <wizonesolutions> and finally to complete ones completed in Habit on the RTM side. but probably all based on the RTM states. e.g. I will simply see that in Habit it's done but it isn't done in RTM and assume that I should mark it complete in RTM
[16:46:48] <wizonesolutions> that way I don't have to cache the state of Habit todos

Elaborating on this, I think goal 1 is actually just to add all tasks to Habit wholesale. Don't even compare. Goal 2 is to compare and not double-add, and so on. So all_goals++;

I am psyched.

If RTM errors out, then we don't want to update our hts_last_known_state property on Habit tasks because then they won't get completed on the RTM side. Not a super-big deal — can just complete the tasks in RTM some time — but just one of those things.

I've switched to The Secret Weapon, which is Evernote-based, and so it'd be nice to have support for Evernote in the tool. This would require additional configuration — the active tasks notebook and the completed task notebook, in particular. I would also need to cache the titles of the tasks somewhere. But an SQLite database (or even nconf) would probably work fine in this case.

For some reason, some of my tasks aren't getting completed in RTM. Maybe I broke this at some point. In any case, would be good to be able to catch them up manually.

Can probably knock out #22 at the same time.

Because Gittip is good.

https://www.gittip.com/wizonesolutions

I should say "again", as I commented before on the HabitRPG blog. ;-) So, I installed the node, and I downloaded the "master" sync file, I typed the install command bit into my terminal, and after the first two lines, I got lots or red errors. :-) Little help?

I'm a big fan of the things programming can do for me, just not so good at actually doing it. I was really hoping to finally get this going-- It's really hard to keep track on my todos during a busy day on the HabitRPG site at the pace it's been responding as of late. Cheers, and thanks for the effort!

Calling it habitsync for now. Don't think I'll clash with anyone, and it's in line with making sure RTM isn't hardcoded too hard even though it's the only thing supported at the moment.

Before integrating more task managers, I need to abstract out the task-syncing logic a bit. Unless someone helps me, I'm not going to go as far as to try and be cool and make a plugin interface or something.

More like just putting the RTM stuff in its own class and maybe having a superclass with some common functions (probably not in v1).

Probably need a config file that sets the default todo-syncing service as well. And a more unified file that tracks state per service (rather than the current set of scattered files).

rtm.tasks.getList has a neat little parameter it takes called last_sync. This ensures you only get new tasks, modified tasks, and deleted tasks since the last time you pulled data.

This is quite neat and means we'll be able to operate incrementally on todos. It means we won't have to do manual comparisons for RTM-side updates; RTM will simply tell us what changed! Then we just funnel it in on our side.

So this is something to do soon.

Hi! First of all, thank you very much for your amazing work! I really need to have hRPG and RTM synchronized, and your work is a wonderful tool to do so!
However, I can't always use my computer, and it would be really nice if there were a way to use this code from a tablet or a phone. It seems that one "simple" way to achieve it would be to be able to turn it into a web app. But I'm not much of a Node.js developer, so, after various unsuccessful attempts, I'm turning to you, to seek your help.

OK, so let's think about recurring tasks again now that I'm a bit fresher.

In my experience, recurring tasks usually fall into one of these classifications (not accounting for outside-of-the-box thinking):

• Task needs to be done every so often, and it must be done (true-recurring type)
• Task should be done every so often (could-be-in-calendar-app-instead type)
• Task is a periodic habit (habit-type). Extra points if they lie uncompleted and the recurrence piles up.

1 and 2 don't really belong in Habit. Todos have a due date, but they don't have any other concept of time per se. I'm not going to support the first two use cases in v1. Actually, I'm not going to support any of them, but I will support use case 3 first, probably via a tag where the user indicates they want to do with it. If it recurs anything-up-to-weekly, it will create a daily with the same recurrence.

Otherwise, I have two options:

• Add them as {type: habit} and leave the user to their own devices. Maybe try to complete/postpone the remote tasks when the user does something. I'm not too confident about that, though.
• Add all the occurrences as {type: todo}. This is probably what I'm going to do. I don't want to deal with recurrence. Let RTM do that. I think taskseries records actually contain all the recurring tasks within them, so that might make my life easier.

Anyone have any actual thoughts?

Could run like every half hour or so. Considering doing this myself. The invocation would be something like FORCE=1 /path/to/habitsync because it has to run non-interactively. I believe the authentication part simply bails if there's anything wrong, so it should exit gracefully in any case.

That would make litenull/lefnire.js#17 more possible.

Word on the street says that Any.do can synchronize with Google Tasks. I use Any.do, and I rather like it. I also need a good alternative task manager for when I develop my Big Idea, so this is in my interest. I would want those tasks to get synced with HabitRPG also.

Punch list for this:

1. Investigate if Any.do really syncs with GTasks.
2. Test it manually; what happens when I check off a GTask task? Does Any.do pick it up? Add and delete also.
3. If all checks out, we continue. If not, might do it anyway. GTasks has a decent Android app, and I could live with it.
4. Implement the standard functionality that RTM already has — add new, delete deleted, complete on GTasks when completed in Habit. Use the hts_gtasks key for custom metadata. hts_external_id and hts_external_source should reflect GTasks also. I didn't put them in there for nothing.
5. Add logic to add a note saying where the task came from, or maybe prefix the task with the service abbreviation. This is because I might import some of my RTM tasks to GTasks, and I want to be able to distinguish them at a glance.

If you beat me to this, send me a pull request! Any.do is popular right? :)

I've heard of this repository thing for Node.js modules, and there are even some scripts/binaries on there! I should get habitrpg-todo-sync up there! Also, it'd let me stop running it with an absolute path...

Anyone who has a good npm publish primer, sound off. I'll dig into it eventually.

I'm expecting to improve the metadata we store for tasks, support due date, etc., but for tasks I've already imported this won't work. So I need a REFRESH environment variable. This will pull in the due date information (and whatever other stuff I might add later) for older tasks.

It will imply FULL_SYNC, but it will PUT tasks with appropriate updated values (if they differ) instead of skipping existing ones.

Should only be shown when DEBUG_MODE is on.

npm ignores everything in node_modules.

@pjf What do you think? Gotten a chance to npm install -g habitrpg-todo-sync this? :)

I don't think due dates do anything yet (@lefnire?) but this is in preparation for when they do.

Sometimes I get undefined responses back from getTasks and completeTask. It might be the RTM API throttling itself, but it's confusing in any case. I need to handle the responses properly. Super Agent normally returns false for res.ok in these cases, but maybe we are getting 200 responses? I need to check for undefined responses in any case and act accordingly. Also for undefined task_ids. For some reason we're calling completeTask with undefined task_id fields sometimes.

This is obviously a bad place for this since it'd have to be a new repo and stuff, but I'm starting to feel the need for this, and it'd be a nice place to play with my Angular skills.

I think v1 is just to put up an app that takes a user ID and API key (for Habit) and gets an auth token from RTM (for RTM). Then it calls habitsync in the background and just captures output and outputs it on the web view.

User input would be sanitized and I'd probably use some library designed for shelling out safely.

v2 would be to abstract out the common functionality into a library or something, make it all smarter.

Unlike the previous asker, I am in WAY over my head. If you have time to explain the installation procedure using very small words (for a n00b using Windows), I would very much appreciate it! Many many many thanks!

pjf/WebService-HabitRPG@d23411e added support for this in hrpg. I should follow suit. This would save me lots of environment variable typing and make debugging easier.