<?xml version="1.0" encoding="UTF-8"?> 
<?xml-stylesheet href="https://dev.horde.org/themes/horde//default/feed-rss.xsl" type="text/xsl"?> 
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"> 
 <channel> 
  <title>Support accumulating timers and ask for time entry when creating timer</title> 
  <pubDate>Fri, 10 Apr 2026 09:21:04 +0000</pubDate> 
  <link>https://bugs.horde.org/ticket/6550</link> 
  <atom:link rel="self" type="application/rss+xml" title="Support accumulating timers and ask for time entry when creating timer" href="https://bugs.horde.org/ticket/6550/rss" /> 
  <description>Support accumulating timers and ask for time entry when creating timer</description> 
 
   
   
  <item> 
   <title>See also Ticket 2667 and Ticket 6549.



Our particular usag</title> 
   <description>See also Ticket 2667 and Ticket 6549.



Our particular usage, as developers, is to accumulate time on given tickets.  For example, work on Ticket #1, finish it, turn it over to test, move on to Ticket #2.  Later, test comes back and complains that Ticket #1 isn&#039;t finished, so we &quot;switch&quot; back to Ticket #1 and repeat.  In a given day, I might have 6-12 tickets under way in this waterfall type process.



Another time this arises in when we double duty &quot;on the desk,&quot; taking support calls.  We&#039;ll be working away on Ticket N, when the phone rings and we go into support mode.  So, we &quot;switch&quot; our task and want to accumulate time on the right one.



Today, one way we handle this is to track our hours in a spreadsheet at our desks: at the end of the day, we sprinkle the worked hours around roughly on all the tasks we worked.



Timers are more accurate, and it seems like timers would be more generally useful if the following modifications were made:

1. When you create a timer, you must fill in the time entry&#039;s &quot;static&quot; information: client, job type, cost object as well as a &quot;name&quot; for the timer.

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.



The idea here is to focus the information you enter at each stage of the timer -- creation and click -- to just the needed information, and to give you the option to continuing timing.  



Thoughts?</description> 
   <pubDate>Mon, 31 Mar 2008 21:03:04 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6550#t44271</link> 
  </item> 
   
  <item> 
   <title>&gt; 1. When you create a timer, you must fill in the time entr</title> 
   <description>&gt; 1. When you create a timer, you must fill in the time entry&#039;s 

&gt; &quot;static&quot; information: client, job type, cost object as well as a 

&gt; &quot;name&quot; for the timer.



I would change &quot;must&quot; to &quot;can&quot;.



&gt; 2. When you click the timer, you see (but cannot edit) the previously 

&gt; entered information.  You also see (but cannot edit) the date and 

&gt; accumulated hours.  You are prompted to enter a description and 

&gt; optionally notes.  You have two options: Save and continue timing, or 

&gt; Save and stop timing.



I don&#039;t exactly follow the interface flow here. And what do you mean with &quot;previously entered information&quot;? Already running timers?

What happens with running timers anyway? Are they paused while another timer is running? Is the last active timer resumed automatically once a later timer has been stopped?



&gt; Thoughts?



I&#039;m not sure, do you consider this as a replacement for the stopwatch, or next to it? Anyway, it sounds like a nice enhancement.</description> 
   <pubDate>Fri, 04 Apr 2008 11:25:04 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6550#t44385</link> 
  </item> 
   
  <item> 
   <title>Ping?</title> 
   <description>Ping?</description> 
   <pubDate>Wed, 25 Jun 2008 16:14:23 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6550#t46810</link> 
  </item> 
   
  <item> 
   <title>&gt;&gt; 1. When you create a timer, you must fill in the time ent</title> 
   <description>&gt;&gt; 1. When you create a timer, you must fill in the time entry&#039;s

&gt;&gt; &quot;static&quot; information: client, job type, cost object as well as a

&gt;&gt; &quot;name&quot; for the timer.

&gt;

&gt; I would change &quot;must&quot; to &quot;can&quot;.



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





&gt;&gt; 2. When you click the timer, you see (but cannot edit) the previously

&gt;&gt; entered information.  You also see (but cannot edit) the date and

&gt;&gt; accumulated hours.  You are prompted to enter a description and

&gt;&gt; optionally notes.  You have two options: Save and continue timing, or

&gt;&gt; Save and stop timing.

&gt;

&gt; I don&#039;t exactly follow the interface flow here. And what do you mean 

&gt; with &quot;previously entered information&quot;?



Client, job type, etc.



&gt; Already running timers?



No.



&gt; What happens with running timers anyway? Are they paused while 

&gt; another timer is running?



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



&gt; Is the last active timer resumed 

&gt; automatically once a later timer has been stopped?



No.





&gt;&gt; Thoughts?

&gt;

&gt; I&#039;m not sure, do you consider this as a replacement for the 

&gt; 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.</description> 
   <pubDate>Wed, 25 Jun 2008 21:08:39 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6550#t46820</link> 
  </item> 
   
  <item> 
   <title>Implemented for Hermes 2.0

See also Request: 12543</title> 
   <description>Implemented for Hermes 2.0

See also Request: 12543</description> 
   <pubDate>Tue, 26 Nov 2013 19:57:21 +0000</pubDate> 
   <link>https://bugs.horde.org/ticket/6550#t81679</link> 
  </item> 
   
   
 
 </channel> 
</rss> 
