This has been a fantastic discussion to follow, and it highlights a classic challenge in software development: different users have genuinely different, valid workflows. Reading through the thread, it’s clear that what is a feature for one person is a nuisance for another.
I think wrongecho summed it up perfectly when he mentioned the wide range of needs. From auto-start, to manual entry, to full start/stop datetime logs. And DDCal's point about this being a prime case for a settings toggle is spot on.
Building on all the great ideas here, what if the solution isn't to pick one method, but to build a flexible system that lets each technician work the way they want to? Here’s a potential phased approach that could make everyone happy:
Phase 1: The Quick Win - Individual Timer Preferences
This seems like the easiest and most immediate fix that would solve the core of the current debate. Instead of a global setting, add it to the user account preferences.
Under My Account, each technician could have a setting called "Default Timer Behavior" with three choices:
Start Timer Automatically: The current behavior. Perfect for those who like it.
Manual Start Only: The timer loads at 00:00:00 and only starts when you click it. This solves the main issue for the 85% in the poll. No more accidental time entries when changing a status.
Manual Entry Only (Hide Timer): Hides the live timer altogether and just shows the time input field. Ideal for on-site techs or anyone who logs their time in blocks after the work is done.
This alone would empower each user to tailor the system to their job without forcing a change on anyone else.
Phase 2: The Smart Upgrade - Status-Based Automation
To solve the problem magixnetworks brought up about timers becoming inaccurate on long-running tickets, we could add an optional "Timer Action" to ticket statuses.
For example, an admin could configure:
This would make the timer much more accurate for its intended purpose without any manual intervention from the tech. Each status would have a checkbox to use the timer or not.
Phase 3: The Long-Term Goal - An Optional 'Advanced' Time Entry Module
This addresses the popular request for PSA-style start/stop datetime logging. Acknowledging wrongecho's point about the database complexity, this would be a major, long-term feature.
It could be an admin-level setting to switch from the current "Simple Timer" to an "Advanced Time Entries" mode. This mode would replace the single timer with a log where techs can add entries with specific start and end times, duration, and notes. This wouldn't replace the simple timer; it would be an optional, more powerful system for those who need it.
This approach seems to cover all the bases:
For the 85%: You get your manual timer (Phase 1).
For the 15%: Your workflow doesn't change at all (Phase 1).
For those who log time after-the-fact: You can hide the timer and just use the input field (Phase 1).
For long-running tickets: The timer becomes more accurate with status automation (Phase 2).
For those needing detailed, billable records: There's a clear path toward a full PSA-style logger (Phase 3).
