Re: [Tsheetx-developers] Simple timesheet editing

[Scott M. <sco...@gm...>]

forgot to "reply all"...

On Mon, May 16, 2011 at 9:51 AM, Scott Miller <sco...@gm...>wrote:

> Peter,
>
> I have already gotten all this to work in the new (2.x demo) version.
>  Please reveiw the simple_action.php and simple.php files to review and test
> this functionality.
>
> -Scott
>
> On Mon, May 16, 2011 at 6:47 AM, Peter Lazarus <pal...@gm...>wrote:
>
>> I have been looking at the simple.php form. I have mostly devised a way of
>> dealing with updates and insertions and deletions, and will soon be coding
>> it up.
>>
>> The way the current code works though is to accept any change and apply
>> it. So if in a previous use of this simple weekly form the user entered some
>> time for client 1/project 1/task 1, and then in a subsequent update, decided
>> that he should have selected client 1/project 2/task 3, he can just go and
>> re-select the new project and task, and the time will now appear under the
>> new project. The current simple weekly timesheet does allow that change to
>> take place.
>>
>> I would like to propose a different way of making such a change. I think
>> that once a user selects a specific client/project/task and enters time
>> against it, then that relationship should be locked down, and not be able to
>> be changed in the future. Hence, the user could change client/project/task
>> on first entering the data, but once he saves his changes, the
>> client/project/task dropdowns should be locked and be unchangeable.
>>
>> Why? Well, with this current design, it is of no importance because all
>> the times records are deleted at start of processing anyway. I no longer
>> want to delete times records enn-mass, but decide to do update, insert or
>> delete times records based on the user editing. From this point of view, the
>> relationship between client/project/task and the entered time is important
>> to manage. And from a database design the relationship should not be changed
>> at will. In future, when the database has some design changes, and perhaps
>> referential integrity is introduced, such a change would not be allowed.
>> Hence I would like to tighten up the user interface now.
>>
>> My suggestion will then require the user to delete the line containing the
>> entered times for client 1/project 1/task 1, and re-enter them on a new line
>> for client 1/project 2/task 3.
>>
>> The alternative approach is to allow the user interface to work as it
>> currently does, allowing the user to change client 1/project 1/task 1 to
>> client 1/project 2/task 3, at any time. Under the covers the change would be
>> implemented by deleting the current times records and inserting new ones
>> with the new client/project/task.
>>
>> What do you think about both approaches? Do you think I am making things
>> more complex?
>>
>> Peter
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Tsheetx-developers mailing list
>> Tsh...@li...
>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>
>>
>