From: Scott M. <sco...@gm...> - 2010-09-22 14:19:27
|
Well, to be honest, the reason I'm currently advocating never to switch between them is because of the various problems that can crop up when doing this. Start/stop times, if they exist, are wiped out to all begin at midnight, and week spanning entries can cause time losses or time replications. There may be others, but these issues are currently non-trivial to fix, but they are easily avoided if you don't switch between the two input methods. I've thought about how to tackle these issues: if we keep track of the transaction ID's within the simple timesheet, that appears to be a workable solution, but then when we throw the aggregation possibilities into the mix, things break down. But, iIf we kept a list of the transactions for the aggregations, maybe that would work? If an aggregate is edited, throw out the individual entries and create a new one that starts at midnight. If it's not edited, leave them alone. For entries with a single transaction, the length could be edited, leaving the start time in tact. This also helps make the week spanning time entries problems more easily solvable. As far as submission to management and approval go, I would highly recommend putting that stuff in separate forms. BTW, many things seem to hinge on having some sort of per user configuration tables. Timesheet submission and approval seem to need these from what I've been able to figure out. I would love to have a per user timezone entry, but then we need to fix the timezone problems... -Scott On Wed, Sep 22, 2010 at 6:05 AM, David Thompson < tom...@us...> wrote: > I would disagree with the view that you shouldn't switch between the two, > why not? Sometimes you just want to say I worked today from 7 to 18, and let > the TS work out how many hours that was, and other times you say OK, > yesterday I did about 4 hours. > > If the simple timesheet didn't have all the problems that Peter has rightly > identified, then it wouldn't be so tricky to swap between the two styles of > entry. I could imagine merging the simple and weekly timesheets and offering > the user the choice of style. > > Cheers > > > From: it...@ea... > > To: pal...@gm...; tsh...@li... > > Date: Tue, 21 Sep 2010 19:37:05 -0400 > > Subject: Re: [Tsheetx-developers] Simple time sheet > > > > > I've got to agree with Scott... If you want to enter start and stop > times, > > use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple > > timesheet works great for those who only need to enter hours and minutes > and > > the start/stop times don't mean anything to us: just the time in the end > > > > -----Original Message----- > > From: Peter Lazarus [mailto:pal...@gm...] > > Sent: Tuesday, September 21, 2010 7:05 PM > > To: tsh...@li... > > Subject: [Tsheetx-developers] Simple time sheet > > > > I posted this comment on simple timesheet entry on the bug tracking > > system. Scott Miller has responded and suggested we discuss this issue > > on the developers forum. Can the wider community add their opinions and > > suggestions. Scott's response is reproduced further down. > > Peter > > > > I've been using the simple timesheet to add a function for submitting and > > approving timesheets. The more I work on my new function I discover that > > simple timesheet has some inconsistencies with the other entry methods. > One > > issue that I don't like is that simple deletes the time records and them > > puts them back. This means quite a lot of detail can be lost. > > > > So can we suggest/design a new time entry format, perhaps similar to > > simple's approach. Some of the requirements I would like to see are: > > - enter times for the week against the projects/tasks > > - time entry must include start and stop times to be consistent with the > > other input > > - multiple periods on the one day against one project/task/description > > similar to what can be entered with daily or weekly > > - changes to existing times cause db updates rather than > > deletion/insertion > > - ability to submit time records for a week for approval (requires a > > supervisor) although submission could be done in another panel > > > > (0000231) Scott Miller (developer) - 2010-09-21 20:05 > > http://bugs.timesheetng.org/view.php?id=109#c231 > > ---------------------------------------------------------------------- > > I agree that deleting records only to recreate them seems to be the wrong > > thing to do, but keeping track of what items need to change then becomes > > necessary and that's not a trivial task. > > > > I totally disagree with requiring a start and stop time. Simple was > > designed for those who don't want to have to deal with start/stop times, > > and just want to be able to record time spent per item. > > > > That said, I believe that if start/stop times exist, they should not be > > deleted; again this is not trivial. > > > > For further discussion, please join the developers mailing list, and lets > > discuss this there. You can find a link in the wiki area to join. > > > > One example of why these are not trivial problems is that simple.php > > currently combines multiple time entries for identical task/log messages. > > How do you handle an edit of an aggregate amount of time? > > > > I personally believe that users should be free to choose which system > they > > want to use, but I highly recommend NEVER switching between time entry > > systems because they represent entirely different ways of > thinking/looking > > at time tracking. > |