Re: [Tsheetx-developers] Simple timesheet editing

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

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

On Mon, May 16, 2011 at 10:10 AM, Mark Wrightson
<ma...@rw...>wrote:

>  Scott,
>
> I acknowledge that you have spent some time making simple.php work once
> again in the 2.x version however I think you have misunderstood what Peter
> is saying.  I think Peter is proposing to rewrite sections of simple.php as
> there are many flaws in how simple currently operates.
>
> I agree with Peter that the client / project / task is too easy to change
> and I think his proposal is a much better one.  Peter is also discussing how
> the current method of deleting everything out of the db before adding it
> back is a poor way of manipulating data.  Just consider if the server
> crashes between sql transactions - you could end up with all the data being
> deleted and not being added back in.
>
> I also believe that simple.php needs to more closely relate to the other
> methods of time entry as there are lots of compatibility problems between
> the two methods.  I realise this is a much discussed point but we really
> can't use the reason "We must give users the option" as validation for
> having two parts of a system that simply don't work together properly.  You
> wouldn't find it in a commercial app, so why find it in this one?  I'm sure
> there is a way (i haven't looked yet) in making the two systems compatible.
>
>
> Regards
> Mark
>
> _____________________________________________
>
> Mob:  07725 695178
> Email: ma...@rw...
>
>
> On 16/05/2011 15:51, Scott Miller wrote:
>
> 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
>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>