LiquidPlanner Classic Forum

Ask a Question
Back to All

RFE: update estimate when committing a timer

(edited)

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!

Admin

Hi Ricardo,

That's a good point. The Track Time method has an optional reduce_estimate parameter (if true, reduces high and low remaining effort estimates by the hours in the work parameter) but Commit method for tracking time from timer does not. I submitted a feature request for this on your behalf.

Admin

Posted on behalf of Ricardo Signes.

I hesitate to post something like "bump," but here I am.

This has grown increasingly pressing, as staff do more and more logging through our Slack integration, which uses this API. Using the timer's commit method takes three API calls:

  1. get /my_timers, find the running timer
  2. get the task, so you know the task activity id; this is required to commit, but is not in the timer object
  3. post to /tasks/ITEM_ID/timer/commit

This doesn't reduce the estimate. To do that, the safest thing seems to be:

  1. get /my_timers, find the running timer
  2. get the task, so you know the activity id
  3. post to .../tasks/ITEM_ID/track_time with work=TIMER_TIME and reduce_estimate true
  4. post to .../tasks/ITEM_ID/timer/clear β€” I'm not sure if this also stops the timer, if not, a 5th call required

(An aside: the response to a successful track_time is not documented. Does it include the new estimate values? I'll go experiment later, but <3 docs.)

The simplest change (from an outsider's perspective) would be to just add reduce_estimate to timer/commit.

Even better would be:

  • make tracking time default to the use activity of the task or the user's assignment on it
  • having a commit-running-timer endpoint

With those two, the whole operation would be:

  1. post to /my_timers/running/commit with reduce_estimate set

This would probably have to return something like a timesheet entry: an object with work, item_id, and activity_id.

The first of these changes would be be theoretically useful without the other, but in practice, we fetch the task so we can display its name.

Anyway, I will probably add the extra step for now, but in my heart I am still hoping you will make it possible to eliminate some API calls to get this done. Thanks!

Furthermore, Carthage must be destroyed.

Admin

Hi Ricardo,

Thank you for the additional color. I hear your pain and I documented your feedback for the team. Unfortunately, to implement this requires more effort than we can spare right now. I'll be sure to let you know if that changes.

To answer your question about response to track_time, you do get the task details back and the assignments on the task will have new estimates.

Marked as answered by LiquidPlanner Support

ο»Ώ