Menu
▾
▴
tsheetx-developers
|
From: Peter L. <pal...@gm...> - 2011-05-16 11:47:59
|
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 |
|
From: Scott M. <sco...@gm...> - 2011-05-16 14:51:53
|
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 >> >> > |
|
From: Mark W. <ma...@rw...> - 2011-05-16 15:10:17
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Scott, <br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
Regards<br>
Mark<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 16/05/2011 15:51, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">forgot to "reply all"...<br>
<br>
<div class="gmail_quote">On Mon, May 16, 2011 at 9:51 AM, Scott
Miller <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm...">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">Peter,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Scott<br>
<br>
<div class="gmail_quote">
<div>
<div class="h5">On Mon, May 16, 2011 at 6:47 AM, Peter
Lazarus <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:pal...@gm..." target="_blank">pal...@gm...</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>
<div class="h5">
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
What do you think about both approaches? Do you
think I am making things more complex?<br>
<font color="#888888"><br>
Peter<br>
<br>
<br>
</font><br>
</div>
</div>
------------------------------------------------------------------------------<br>
Achieve unprecedented app performance and reliability<br>
What every C/C++ and Fortran developer should know.<br>
Learn how Intel has extended the reach of its
next-generation tools<br>
to help boost performance applications - inlcuding
clusters.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/intel-dev2devmay"
target="_blank">http://p.sf.net/sfu/intel-dev2devmay</a><br>
_______________________________________________<br>
Tsheetx-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:Tsh...@li..."
target="_blank">Tsh...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers"
target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devmay">http://p.sf.net/sfu/intel-dev2devmay</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-05-16 16:28:31
|
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 > > |
|
From: Mark W. <ma...@rw...> - 2011-05-16 16:33:54
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
How about a check box next to the drop down boxes that must be
checked to enable the changing of the project / client / task
section? I agree that you dont want a popup warning - too obtrusive,
however a simple tick box that must be clicked to enable editting of
the boxes (one for each row) would resolve that problem completely.<br>
<br>
Mark<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 16/05/2011 17:28, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">Ok, yes, I didn't read the initial email very well.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.
<div>
<br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Scott<br>
<br>
<div class="gmail_quote">
On Mon, May 16, 2011 at 10:10 AM, Mark Wrightson <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> Scott, <br>
<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
Regards<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" value="+17725695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<div>
<div class="h5"> <br>
On 16/05/2011 15:51, Scott Miller wrote:
<blockquote type="cite">forgot to "reply all"...<br>
<br>
<div class="gmail_quote">On Mon, May 16, 2011 at
9:51 AM, Scott Miller <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:
0pt 0pt 0pt 0.8ex; border-left: 1px solid
rgb(204, 204, 204); padding-left: 1ex;">Peter,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Scott<br>
<br>
<div class="gmail_quote">
<div>
<div>On Mon, May 16, 2011 at 6:47 AM,
Peter Lazarus <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:pal...@gm..."
target="_blank">pal...@gm...</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">
<div>
<div> 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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
What do you think about both
approaches? Do you think I am making
things more complex?<br>
<font color="#888888"><br>
Peter<br>
<br>
<br>
</font><br>
</div>
</div>
------------------------------------------------------------------------------<br>
Achieve unprecedented app performance
and reliability<br>
What every C/C++ and Fortran developer
should know.<br>
Learn how Intel has extended the reach
of its next-generation tools<br>
to help boost performance applications -
inlcuding clusters.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/intel-dev2devmay"
target="_blank">http://p.sf.net/sfu/intel-dev2devmay</a><br>
_______________________________________________<br>
Tsheetx-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:Tsh...@li..."
target="_blank">Tsh...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers"
target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
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.
<a moz-do-not-send="true" href="http://p.sf.net/sfu/intel-dev2devmay" target="_blank">http://p.sf.net/sfu/intel-dev2devmay</a></pre>
<pre><fieldset></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" href="mailto:Tsh...@li..." target="_blank">Tsh...@li...</a>
<a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers" target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</div>
</div>
</div>
<br>
------------------------------------------------------------------------------<br>
Achieve unprecedented app performance and reliability<br>
What every C/C++ and Fortran developer should know.<br>
Learn how Intel has extended the reach of its
next-generation tools<br>
to help boost performance applications - inlcuding
clusters.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/intel-dev2devmay"
target="_blank">http://p.sf.net/sfu/intel-dev2devmay</a><br>
_______________________________________________<br>
Tsheetx-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:Tsh...@li...">Tsh...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers"
target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devmay">http://p.sf.net/sfu/intel-dev2devmay</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Peter L. <pal...@gm...> - 2011-05-16 23:00:18
|
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 > |
|
From: Peter L. <pal...@gm...> - 2011-05-16 23:24:20
|
On the subject of database integrity which I raised in my previous email
on the simple timesheet:
I notice in task_maint.php this pop-up message:
if (confirm('Deleting a task which has been used in the past will make
those timesheet ' +
'entries invalid, and may cause errors. This action is
not recommended. ' +
'Are you sure you want to delete this task?'))
There is a recognition of creating errors by deleting a task. This is
all about database integrity, but it's not handled at all well.
task_action.php deletes entries from the task_table and the
task_assignments table, which leaves all the times table entries with a
task number that no longer exists. I guess at the time it was a bit too
complex a situation to handle and wasn't cleanly implemented.
But it is an illustration of why data integrity is important, and that
we should code for it.
A database is a different entity to a collection of files.
Peter
|
|
From: Peter L. <pal...@gm...> - 2011-05-16 23:57:34
|
Sorry, forgot to copy the list
On 05/17/2011 09:45 AM, Peter Lazarus wrote:
> Haha, ah yes, I forgot about data aggregation. And of course that
> reminds me of the times crossing daily boundaries. Ok, I am going to
> abandon the simple.php cause for now and go work on something else.
> (I've got an Android application that needs updating :-) )
>
> Regarding my son's issue, and the bug reported in Mantis, you think
> it's limited by the post size? I must look into that, and then if that
> works, I can close off the Mantis bug as well. Thanks Scott.
>
> Peter
>
> On 05/17/2011 09:38 AM, Scott Miller wrote:
>> Editing items in the database using the transaction numbers doesn't
>> work due to the fact that the simple sheet may aggregate multiple
>> items into a single number. This is just one example of the types of
>> issues you have to deal with, and why items are deleted and then
>> re-added.
>>
>> Regarding your son's issues, raise the amount of data php is allowed
>> to post to a sane number (32 meg for instance), instead of
>> restricting it to a tiny amount. In the /etc/php,ini file on linux.
>>
>> -Scott
>>
>> On Mon, May 16, 2011 at 6:24 PM, Peter Lazarus <pal...@gm...
>> <mailto:pal...@gm...>> wrote:
>>
>> On the subject of database integrity which I raised in my previous
>> email
>> on the simple timesheet:
>>
>> I notice in task_maint.php this pop-up message:
>>
>> if (confirm('Deleting a task which has been used in the past will
>> make
>> those timesheet ' +
>> 'entries invalid, and may cause errors. This
>> action is
>> not recommended. ' +
>> 'Are you sure you want to delete this task?'))
>>
>> There is a recognition of creating errors by deleting a task.
>> This is
>> all about database integrity, but it's not handled at all well.
>>
>> task_action.php deletes entries from the task_table and the
>> task_assignments table, which leaves all the times table entries
>> with a
>> task number that no longer exists. I guess at the time it was a
>> bit too
>> complex a situation to handle and wasn't cleanly implemented.
>>
>> But it is an illustration of why data integrity is important, and
>> that
>> we should code for it.
>>
>> A database is a different entity to a collection of files.
>>
>> 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...
>> <mailto:Tsh...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>
>>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X