ForumsSearch
Search results for "Posted by safire"
| Author | Message |
|---|---|
|
safire |
Hi -- Great to see an update to the API. I wanted to know if the list of changes on the linked page (https://api/toodledo.com) can be considered a complete change list, or if this is only highlights.
Basically, I'm interested in upgrading my existing application that uses the v2 API and want to know just how much I actually need to touch to get it working. The documentation is fairly extensive (both for v2 and v3), and I haven't been working directly with the v2 API for quite a while, so I'm looking for pointers without trying to do a line by line comparison of the two docs. If the above mentioned list is complete, that looks like it might be enough to go on. I'd appreciate any feedback from other developers about the migration process from v2 to v3. Thanks! |
|
safire |
Posted Dec 08, 2013 in: Forum Paging with Date Range is broken
Score: 0
It seems that there is a problem with the paging links when searching with a duration.
I start by searching for "collaboration", then select "in the last year". This gets me to page 1 of 2 pages as desired: https://www.toodledo.com/forums/search.php?search=collaboration&searchPerson=&dateRange=365&fid=2&ti d=0 But then I click to the next page, and it drops my date range: https://www.toodledo.com/forums/search.php?fid=2;tid=0;page=1;search=collaboration And this gives me page 2 of 14 (all results since the dawn of time). If I manually add ";dateRange=365" to the end of that URL it properly gives me the right page 2. |
|
safire |
I'm also interested in the motivation behind the new outlines feature. Adding a new feature like this must have started with some unique set of requirements that is different from the tasks model. Can you share?
I also have long wanted a sub-sub-task capability, so it's extremely frustrating to see that it showed up 1) in another feature entirely, and 2) still unavailable via the API. Seems to me that outlines are really just specialized interface to tasks (with support for unlimited hierarchy). I think it would be fantastic to be able to view and add tasks via this interface. For example, I'd start a new project via the simplified "outline" interface in a brainstorm session. Quick, easy, simple view to get started. Then, when I'm done I can go back to the normal task view to formalize it, add priorities/due dates/etc. As it is the outline feature is really a toy. You have the example of "How to buy a house" -- which is actually quite perfect. But that's just the starting point. Where do I take notes? When was that task completed? How do I know what the important next steps are for the coming week? As a developer, I'd think the underlying data model of outlines would be *precisely* the same as the tasks model, because as far as I can tell an "outline" task has a subset of the fields and capabilities of a normal task (with the sole exception of unlimited hierarchy). As such, "Outlines" should be just UI sugar on top of a filtered set of tasks. My suggestion: 1. Add unlimited hierarchy to tasks 2. Make "outlines" basically a special UI for interacting with a saved search of tasks One key benefit of this approach is that you need to do *nothing* to support this via the API because you already have all the info in the tasks, including parent relationship for tasks. This message was edited Sep 29, 2013. |
|
safire |
Posted Aug 15, 2013 in: How should clone with subtasks be implemented?
Score: 0
In my app, I just use a negative number. Makes it easy to identify tasks which are not yet synced with the server. ;-)
|
|
safire |
I'll second this request, as I do exactly the same thing. I end up clicking "edit" just to see it in courier font.
Even better, add support for more tags: * list tags <ul> <li> * table tags <table> <tr> <td> Or, just go with a wiki model of simplified text input. |
|
safire |
Posted Feb 20, 2012 in: Recommendation for Personal/Private Wiki?
Score: -1
I've had good experience with both TWiki and DokuWiki. Both support download for installation on your personal web server. I think both also support hosted wikis if you don't have your own server. Syntax between the two is almost identical. DokuWiki is probably going to be easier / more lightweight in terms of configuration and setup.
|
|
safire |
Posted Feb 20, 2012 in: Setting for subtasks to always inherit folder from parent
Score: 0
I've been working on org-toodledo (emacs integration with org-mode) and been thinking about how to add folder support and as a result I have a feature request.
Basic problem: There is no strict relationship between the folder assignment of tasks and subtasks. Feature Request Add a setting to Subtasks: [x] Subtask's folder always inherits from it's parent This would work as follows: 1. Creating a subtask C of task P sets C's folder to that of P 2. Making an existing task C a child of task P sets C's folder to that of P, even if C previously had a different folder assigned. 3. Promoting a subtask C to a top-level task retains the folder assigned to it. 4. Make the setting available via the Developer's API Details I spent a fair amount of time searching the forums for discussions about this topic, and here's what I've gathered. Folders are not really much more than a special tag on a task which enables filtering. In the sense that you can build a view that is restricted to a single folder gives the impression that the folder provides grouping. However, this is not much different than the view by context or tag. In fact there has certainly been confusion on the list about the difference between the proper use of context versus folder. If used according to GTD, context denotes something about where a task can be completed, thus has some special meaning that can be leveraged. But I can find no such special meaning for folders. It is clear that some folks use folders just like a special tag. Proximo's famous GTD methodology uses folders in this way, assigning the task to a folder to denote the state of a task (Inbox, Actions, Projects, Waiting...). There is already a Status field for each task that performs almost the same function, which some have pointed out. As I understand it, Proximo simply used Folder as it provided the flexibility needed to implement GTD in a way that made sense to him. However, the standard concept of a folder really does not apply. By that I mean a folder is generally a fairly rigid grouping construct. If you put an item in a folder, that item and all of its dependencies are in that folder. Currently, Toodledo with folder as an attribute allows for the following: * Parent task (Folder=FOO) ** Subtask 1 (Folder=BAR) ** Subtask 2 (Folder=None) Expected behavior: * Parent task (Folder=FOO) ** Subtask 1 (Folder=FOO) ** Subtask 2 (Folder=FOO) In this way, folder really need only be assigned to top-level tasks (or alternately read-only for subtasks). It could be better visualized as follows: * Folder FOO ** Parent task *** Subtask 1 *** Subtask 2 This is much more intuitive to me, and now gives "folder" a special meaning apart from a tag -- a task and all it's subtasks are part of the folder. Moving the task to a new folder changes all the sub-tasks as well. This is not a behavior I want for tags in general. Why do I care? As I implement this in Emacs org-toodledo, I cannot find any way to meaningfully distinguish between a "folder" and a "tag", other than the fact that a task can only be associated with one folder, which doesn't seem terribly interesting to me. I had hoped to use folder as a higher level construct like my example above, and the user can certainly create views of tasks by filtering on folder, but such a view is no different than filtering on any other tag. Given that there are no doubt plenty of users that use folder as a tag and have subtasks with different folders (like the first example), I don't really expect a wholesale change here, the feature request for a new setting to enable this behavior. This message was edited Feb 20, 2012. |
|
safire |
Posted Feb 19, 2012 in: Emacs org-mode integration with org-toodledo
Score: 0
Announcement of new version: 2.6
I have made a lot of improvements and bug fixes. Current version is 2.6 and now supports folders and sub-tasks. README file on github has complete details of all that's supported. ...cj |
|
safire |
Posted Feb 19, 2012 in: Timezone problems with duetime
Score: -1
I can confirm that the time that comes back via "duedate" is noon GMT, not midnight. I figured that this is to minimize the likelihood that you'd have to pay attention to timezone if converting to a date, as for any timezone +/- 12 hours from GMT (which is almost all timezones), you'll still be in the same date.
|
|
safire |
Posted Jan 30, 2012 in: Timezone problems with duetime
Score: -1
Posted by Toodledo:
In fact, we do store time as seconds since midnight in our database. We convert to GMT for the API, because our developers requested this. Heh...got it. Not a big deal, I can adapt. I just wanted to make sure I understood how things are supposed to be working and that it is intentional. May I suggest a change to the documentation for the API as follows: duetime : A GMT unix timestamp for when the task is due. If the task does not have a time set, then this will be 0. If the task has a duetime without a duedate set, then the date component of this timestamp will be Jan 1, 1970. Only the time relative to midnight GMT is important. For example "Jan 13 8:00am GMT" means the task is due at 8:00am on the date of interest in the local timezone. This time must not be adjusted for the local timezone. Similar for starttime. Thanks! |
|
safire |
Posted Jan 30, 2012 in: Error while setting completed date
Score: 1
Posted by Toodledo:
True, it is more of a warning than an error, but we don't have a method for sending warnings back to the requester. We figured that a developer would get this error once, and then look it up and fix their code so it would never happen again. We disallow these fields in the request to save bandwidth. I know that 10 bytes may not seem like much, but when you multiple it by the millions of API calls we get per day, it really adds up on our end, which is why we are aggressive about sending and requesting the minimum amount of data necessary. Yep -- makes sense. One suggestion, change the message slightly to: {"errorCode":3,"errorDesc":"id,title,modified,completed do not need to be specified *in the fields parameter*"} I know I hit exactly the same problem when writing my API, and took me a bit to figure out what exactly the problem was. |
|
safire |
Posted Jan 30, 2012 in: Timezone problems with duetime
Score: 1
So as I think about this, I think the feature you are going for is along the lines of an alarm clock as opposed to scheduling a meeting. I get up daily at 6am, so I set my alarm clock to 6:00am. If I travel to a different timezone, I still get up at 6am, thus it would be convenient if the alarm stayed at 6am.
If this is the case, then duetime and starttime should really not be stored in GMT time, and instead stored as seconds since midnight. Storing the duetime as a UNIX timestamp implies that the time is sensitive to timezone, and thus has been adjusted to account for local time. |
|
safire |
Posted Jan 29, 2012 in: Error while setting completed date
Score: 1
You need to drop "completed" from the list of fields that you are updating. In your case that means your list of fields is empty. See http://api.toodledo.com/2/tasks/index.php, look for the description for "fields":
Always returned (do not list in the fields paramater): id, title, modified, completed As a request to the Toodledo folks, this really need not be an error.... |
|
safire |
Posted Jan 29, 2012 in: Timezone problems with duetime
Score: -1
FYI -- the Toodledo iPad application suffers from the same problem. Setting the time in the iPad app stores the time as relative to GMT and does not seem to pay attention to the timezone of the iPad.
|
|
safire |
Posted Jan 29, 2012 in: Timezone problems with duetime
Score: 1
I am seeing any issue with timezones and the duedate/duetime fields. Here's what I'm doing:
1. Verify my timezone -- I went to the account settings page and it shows my current local time (-5h -- Eastern), so that's correct. 2. Create a task on toodledo.com. Set the Due Date/Time to "Jan 30, 2012 at 10:00am". It shows up properly on the website as tomorrow 10:00am". 3. Retrieve the task via the api and I get back a unix timestamp for duetime=1327917600, which converted to a string is: duetime = 1327917600 GMT time = 2012-01-30 10:00:00 GMT EST time = 2012-01-30 05:00:00 EST (-0500) This seems wrong to me. Since the timezone on the website is set to -0500, then setting the due time to 10:00am should be interpreted as 10:00am EST, not GMT. Also, when I change my timezone on toodledo.com account settings page to -0400, and then look at my tasks, it still says the task is due at 10:00am. It should now read 11:00am because of the 1h change. |
|
safire |
Posted Sep 07, 2011 in: Emacs org-mode integration with org-toodledo
Score: 2
Hi Folks,
I'd like to announce the initial release of org-toodledo.el using the 2.0 API. If you're a user of Emacs, this allows you to synchronize tasks with a file in org-mode. Most features are fully supported: * bi-directional synchronization of all tasks * task completion, state tracking * priorities, contexts, start time, due date Support for Folders and sub-tasks to come... org-mode itself is a powerful organization system for Emacs that extends beyond just tasks. Mixing in tasks and synchronizing with Toodledo extends it's reach to the web and my iPhone for the most pressing well defined actions. org-toodledo on github Enjoy! ...cj |
|
safire |
I'd like to resurrect this question. It used to exist in the old 1.0 API via getServerInfo API call and I'm trying to update an application that is built of the old API and bring it up to 2.0.
I may not be thinking about this properly, but here's my logic: Getting the server type is necessary to determine if there is a time offset between my computer and the server (ie. one of us is not properly NTP synced). That seems to cause problems when attempting to compare timestamps between tasks that were edited both locally and on the server. I'd rather get the current server time, compare with local time to see if the times are off and use the offset for all time-based comparisons. |