Re: [Tsheetx-developers] Simple timesheet editing

[Peter L. <pal...@gm...>]

Scott,
I hadn't realised you had done additional work on simple_action.php. I 
thought you were re-designing the form based on the newdaily.php proposal.

I was actually making some changes to simple_action.php on a local copy 
at the tsng 1.5.2 level on my son's company server. He has real 
difficulty with one of the bugs in the simple timesheet, where it 
appears to lose entries when more than 10 entries are made on a day (bug 
65 in Mantis). I haven't been able to find a reason behind that bug yet. 
Another reason I was working on the code at the 1.5.2. level is that 
tsng-2.0 simple.php doesn't work for me. There are no 
client/project/task dropdown's populated.

I have looked at what you have updated in simple_action.php and 
simple_class.php. The basis of the changes you have made are to save on 
the form the values of the original variables. Then in simple_action.php 
you are able to detect a change by comparing the old with the new value. 
New code has been added to record the old description and hours for 
example. The original form kept track of changes to client/project/task 
and you have used these fields for detecting changes. For example, 
differences between task_row and taskSelect_row show a change to the 
task selection in a row.

Being able to identify a change in the record is good. However I would 
use that information to do a database update rather than deletion.

I have a big problem with deleting database records. It exposes us to 
the loss of data from database failure or system failure (e.g. the 
system goes down between the time the database records are deleted and 
replacement ones are inserted). It leads to additional space usage in 
the database, which might mean more maintenance. But above all, it can 
result in loss of database integrity. At the very least, deletions and 
associated insertions should be done using START TRANSACTION and COMMIT 
statements, which ensure that the combined delete and insert are all 
done, or all not done, no half-way houses.

Now I know that our database design is reasonably simple, and database 
integrity has not been much of a consideration previously. But database 
integrity is important, and we should consider it going forward.

hence what I would propose is the following:
1. if the hours have changed, then do an update of an existing record
2. if the client/project/task/description fields have changed, then do 
an update of an existing record, even though that violates database 
integrity
3. if a new record is created, do an insert
4. if a record is deleted, then delete those time records

This proposal no longer deletes database records except where the user 
requests it as in item 4. above.

Item 2 I don't really like, even though I propose it, because of 
database integrity problems. This is why I raised the idea of locking 
down client/project/task after the first time a timesheet record is 
created. However, I can compromise at this time and allow users to 
change client/project/task. By the way, the commercial timesheet systems 
I have used don't allow this type of operation though - once you choose 
a client/project/task you are stuck with it.

Comments please
Peter

On 05/17/2011 02:28 AM, Scott Miller wrote:
> Ok, yes, I didn't read the initial email very well.
>
> However, I did modify the simple sheet so that it no longer deletes 
> things "en-mass", only deleting and recreating those entries that have 
> changed.  I had thought about even keeping track of the transaction 
> numbers so those items could simply be changed, but there are deep, 
> problematic issues to deal with if that is desired, so I didn't do any 
> work for that.
>
> Originally "re-selecting" a new client/project/task actually failed to 
> work at all; I'm not remembering exactly what used to happen, but I'm 
> thinking the entries totally disappeared on you when you tried to do 
> this.  I did quite a bit of work to allow users to simply change those 
> and keeping the time entries.  There are times when management might 
> tell people to file their hours under some other project/task from 
> what they'd originally done, and making them re-key in all that data 
> isn't exactly "user friendly"; so I would argue that dis-allowing this 
> functionality is the wrong way to go.  I can see an argument that it 
> may be too easy to change those, and an additional "are you sure" 
> dialog box could be added, but, personally, I hate those things; and 
> it's simple enough to change it back, I'd argue it's not needed.
>
> Again, please review the simple files and see for yourselves how data 
> is determined to have changed and all; much of that work has already 
> been done.
>
> -Scott
>