[Tickets #6550] Re: Support accumulating timers and ask for time entry when creating timer

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/6550
------------------------------------------------------------------------------
  Ticket             | 6550
  Updated By         | php at ideacode.com
  Summary            | Support accumulating timers and ask for time entry when
                     | creating timer
  Queue              | Hermes
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


php at ideacode.com (2008-06-25 17:08) wrote:

>> 1. When you create a timer, you must fill in the time entry's
>> "static" information: client, job type, cost object as well as a
>> "name" for the timer.
>
> I would change "must" to "can".

In our usage, it's a must, as that information is required.   
Generally, though, can seems more appropriate.  The salient point is,  
I think, that once you've committed to that information (regardless of  
whether there is any info or not), you cannot change it later.


>> 2. When you click the timer, you see (but cannot edit) the previously
>> entered information.  You also see (but cannot edit) the date and
>> accumulated hours.  You are prompted to enter a description and
>> optionally notes.  You have two options: Save and continue timing, or
>> Save and stop timing.
>
> I don't exactly follow the interface flow here. And what do you mean
> with "previously entered information"?

Client, job type, etc.

> Already running timers?

No.

> What happens with running timers anyway? Are they paused while
> another timer is running?

Yes, only the "active" timer is running.  All others are paused.  You  
may switch to another and have it activate while the others pause.

> Is the last active timer resumed
> automatically once a later timer has been stopped?

No.


>> Thoughts?
>
> I'm not sure, do you consider this as a replacement for the
> stopwatch, or next to it? Anyway, it sounds like a nice enhancement.

I find the stop watch to have zero utility, so I would consider it a  
replacement.  However, the general utility of the stopwatch may be  
needed, so an addition would likely be best.