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

* Your Email Address
* Spam protection	Enter the letters below: . ..__..___.___. . \|\/\|[__][__ \| \| \| \|\| \|\| \| \__\|
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries