LiquidPlanner Classic Forum

*Posted on behalf of Lee Raybone. Original posting date 2018-04-10.* Can someone advise on the following: I'm trying to create a timer control function to start, stop and then "use" the hours logged on a task. I am successfully starting and stopping the timer but I cannot seem to get the hours to log against an activity on a task can someone advise? Regards, Lee

*Posted on behalf of Ricardo Signes. Original posting date 2018-02-27.* A team member here reported that our LP chatbot's "commit my timer but leave it running" command was no longer working. I have just confirmed that when we hit timer/commit with restart:true, the timer is not restarted. This seems like a bug.

*Posted on behalf of Ricardo Signes. Original posting date 2017-08-28.* I'm still using the "commit timer" endpoint all the darn time: https://developer.liquidplanner.com/discuss/5d5c3e3db0a1f80107d08dca I somehow only realized last week that its behavior is quite different from using the timer in the web UI. On the web, if I have a task with a 1-2h estimate and I commit a 5m timer, I end up with a 55-115m estimate of remaining work. Via the API, if I omit "low" and "high" when committing a timer, the estimates are left unchanged. I think this is worse than having the default behavior be to change the estimate. If I must do the change manually, I need to do an extra HTTP request to retrieve the task under consideration to get its existing estimates, then do math with floor() calls to prevent going down below a zero estimate. If you don't want to change the default behavior, how about a boolean adjust_remaining argument that I can set true to get the behavior I want? Thanks!

*Posted on behalf of Lee Raybone. Original posting date 2016-08-23.* Is it possible to control a timer for a task and an particular activity on that task via the API? Regards, Lee

*Posted on behalf of Ricardo Signes. Original posting date 2014-08-20.* API methods for dealing with a timer look like this: /api/workspaces/:id/tasks/:task_id/timer/commit This means that to implement a feature like "stop the current timer" or "commit work on current timer" there are two API calls required: API: get all timers LOCAL: find the timer, among those, that is running API: make API call using the timer's task_id I suggest that there be a path like this: /api/workspaces/:id/user/:userid/current_timer ...and that the endpoints found on any given timer also be found here. They should, of course, return 4xx codes when there is no current timer. Note that I have included the userid. Right now, the API does not allow one to interact in any way with the timers of a non-self user. I think this is a real shortcoming. If it is ever addressed, having current_timer under the userid will mean that there is an obvious way to get the API of a non-self user (which for now can just issue Forbidden).

*Posted on behalf of Ricardo Signes. Original posting date 2014-01-17* Imagine that I have an active timer. It has two hours elapsed. I would like to commit that time to its task, clear the timer, and add a comment to the task. Right now, this would take four API calls: * get timers * clear timer * add comment * track time If any one of these fails, I'm left in a half-committed state, because there is (of course) no way to make an atomic set of transactions across multiple API calls. It would be **excellent** if this API endpoint could also optionally stop the timer and mark the task done. Here is what I propose: POST /api/workspace/:workspace_id/tasks/:task_id/timer/commit Payload is a JSON Object with the following properties: * comment: optional string; a comment to add to the task * stop: optional boolean; whether to also stop the timer * is_done: optional boolean; whether to mark the task done Please note that "comment" should be a comment on the task. The UI provides a way to comment while logging time, but it becomes a "task note," not an item comment, which is almost never useful. On the other hand, I believe the "comment" property on a "track_time" POST makes an item comment, as one would expect. I would find this enhancement to be **extremely** useful