Menu
▾
▴
tsheetx-developers — Timesheet Next Gen - Developer's mailing list
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(10) |
Jun
(1) |
Jul
(3) |
Aug
(19) |
Sep
(52) |
Oct
(5) |
Nov
(15) |
Dec
|
| 2011 |
Jan
|
Feb
(65) |
Mar
(53) |
Apr
(55) |
May
(37) |
Jun
|
Jul
(1) |
Aug
(17) |
Sep
(28) |
Oct
(7) |
Nov
|
Dec
|
| 2012 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Isabelle V. <ver...@fr...> - 2011-05-24 18:00:11
|
Hello, I had time today to work on txsheet-2.0-demo. In this revision: new modifications for internationalisation (en-GB, fr-FR). Sincerely. Isabelle. |
|
From: David T. <tom...@us...> - 2011-05-19 06:47:58
|
So my bleeding-edge suggestion is now mainstream. Like I said PHP is developing quicker than us. Lets hope 5.3 is stable. > Date: Wed, 18 May 2011 17:53:22 +0100 > From: ma...@rw... > To: tsh...@li... > Subject: [Tsheetx-developers] PHP Version > > Hi All, > > I noticed something on the PHP homepage today that I thought I should > share with you as it is related to choosing which versions of PHP our > application should support. > > PHP Guidelines as of 12-Mar-2011 are: > "All PHP users should note that the PHP 5.2 series is NOT supported > anymore. All users are strongly encouraged to upgrade to PHP 5.3.6." > > Therefore I feel if PHP aren't supporting 5.2.x then we have no reason > to either. From this point forward I propose we target 5.3.x > > Mark > |
|
From: Mark W. <ma...@rw...> - 2011-05-18 16:53:25
|
Hi All, I noticed something on the PHP homepage today that I thought I should share with you as it is related to choosing which versions of PHP our application should support. PHP Guidelines as of 12-Mar-2011 are: "All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.6." Therefore I feel if PHP aren't supporting 5.2.x then we have no reason to either. From this point forward I propose we target 5.3.x Mark -- _____________________________________________ Mob: 07725 695178 Email: ma...@rw... |
|
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
>>
>>
|
|
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: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: 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: 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 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 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: 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: David T. <tom...@us...> - 2011-05-11 12:13:14
|
http://bugs.timesheetng.org/roadmap_page.php I've just gone a bit mad updating Mantis, take a look. Everything is open for discussion, nothing is written in stone. The roadmap shows all issues with "target version" in the future. There are also a number of issues with no set target version. If you feel you are working on one of these issues great, if you don't "find yourself" consider creating a new issue and assign yourself. -Tommo |
|
From: David T. <tom...@us...> - 2011-05-11 11:06:14
|
I guess you found the right place already but the link is http://bugs.timesheetng.org Anyone else need r/w access? > Date: Wed, 11 May 2011 11:32:44 +1000 > From: pal...@gm... > To: tsh...@li... > Subject: [Tsheetx-developers] Access to Tracker > > Dave, can you modify my account to allow r/w access to tracker please? > 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: Peter L. <pal...@gm...> - 2011-05-11 01:32:55
|
Dave, can you modify my account to allow r/w access to tracker please? Peter |
|
From: Peter L. <pal...@gm...> - 2011-05-10 23:30:40
|
Dave, or anyone, further to the use of Mantis. If this tracker thing I refer to below is Mantis, can you give me some guidance on how you think it should be used? I see lots of requests, which have really been ignored! So for version 2.0, should we add a list of features into Tracker? For requests that will be met, e.g. time submission, how to link the existing request 896278 to the new feature, and how to be able to see the feature list in 2.0 at one spot? Peter On 05/10/2011 10:12 PM, Peter Lazarus wrote: > Dave, > I haven't looked at Mantis before. Is this it: > http://sourceforge.net/tracker/?group_id=33621&atid=408909 > <http://sourceforge.net/tracker/?group_id=33621&atid=408909> > > You mention it may it not be as agile as other tools, but I don;t > think that matters. Something simple, easy to use, and which provides > some planning and direction will be fine. > > Why didn't I want to publish the list? Just so us developers won't be > under any pressure. And you answered that issue with the "politely > ignore". > > peter |
|
From: Peter L. <pal...@gm...> - 2011-05-10 12:13:05
|
Dave, I haven't looked at Mantis before. Is this it: http://sourceforge.net/tracker/?group_id=33621&atid=408909 You mention it may it not be as agile as other tools, but I don;t think that matters. Something simple, easy to use, and which provides some planning and direction will be fine. Why didn't I want to publish the list? Just so us developers won't be under any pressure. And you answered that issue with the "politely ignore". peter On 10 May 2011 20:10, David Thompson <tom...@us...>wrote: > Peter > Just to take up one of the points you make - feature lists and versions: > > We have used Mantis in the past, and I think it covers your wish very well. > You can allocate any issue to a proposed version and manage the roadmap > well. It may not be as "agile" as other tools, but I can live with that. And > it demands a discipline from the developers => make sure you know on which > issue you are working, and update it too. > > The other thing is, is that it is open and transparent. Anyone who > registers can see the development status. This, I believe, is crucial to > open source development. Why do you not want to publicise what we are doing? > > If you look through the Mantis database, there is at least one example > where users have raised problems and pushed to get them resolved. How did we > handle the pressure? Polite ignoring. We can handle the pressure. > Everyone should accept that this is, as you say, an amateur effort, and if > you need mission-critical professional support then TSNG is not the app for > you. > > Saying that, I am a professional developer and I can send my contact > details to anyone willing to pay my hourly rate :-) Mind you, if anyone > needs help with 2.0, I'm not the man to hire - I haven't looked at the code > in quite a while! > > > Date: Tue, 10 May 2011 13:28:48 +1000 > > From: pal...@gm... > > To: tsh...@li... > > Subject: [Tsheetx-developers] Testing and target releases > > > > The PHP support issue suggests we consider a couple of other issues. > > These issues are a) some form of testing b) some feature lists and > versions. > > > > If we are going to write and release software versions then some test > > process and check-off process is needed. > > > > We are all working away to change things, but it is about time I think > > to set some goals which we can focus on. A set of goals also allows some > > software features to be released. Otherwise I feel we will be coding > > until next year. If we agree on some feature based goals, without target > > dates, then that gives us a way forward. The reason I said no target > > dates is we are all volunteers with our lives to lead, so working toward > > date targets will be difficult. > > > > So I suggest we compile a list of features we are working on, along with > > their state of achievement. From that list we can aim to complete our > > features and get them out there. I would suggest we keep our feature > > list and release targets on the developer list only, and not publish it. > > Then there is no pressure to get things released. > > > > Here is a short paper discussing some of the issues in software release > > related to SubVersion 1.5. > > > http://www.google.com.au/url?sa=t&source=web&cd=3&ved=0CDEQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.143.4757%26rep%3Drep1%26type%3Dpdf&ei=-azITeq1BoTsuAP-ncjcBQ&usg=AFQjCNFzQFzKlcwgp24ouyLd8wl3jAiA7w > > > > For testing, we could use some open source web testing tools. However > > these tools would require a fair bit of work to set up. Here is an > > article on three of them: > > > http://www.infoworld.com/d/architecture/three-open-source-web-service-testing-tools-get-high-marks-995?page=0,0 > > > > And here are comments on even more tools: > > > http://stackoverflow.com/questions/79733/best-automated-testing-tool-for-web-applications > > > > Alternatively, we could create a simple one page list of tests that a > > release needs to achieve before its release. > > > > 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: David T. <tom...@us...> - 2011-05-10 10:53:37
|
Given that I am not actively developing, and don't really have any say... Goal: - release name v2.0 - really "next gen", ie quantum leap from the current version. - new look and feel - at least the same functionality as the current version - i18n - what else? - release date end of august 2011 (august is a year since the last release) How about that? Dave > I also agree with Peter that we should finalise a list of updates for > the next release and push them out by a particular date. > If we said 1st September release is our target, that would seem > reasonable to me? > > Mark > |
|
From: Mark W. <ma...@rw...> - 2011-05-10 10:16:52
|
I think Unit (PHPUnit) testing would be a good way to go. If we are going to spend time testing, we may aswell spend time upfront writing the tests as once it is done it is done. The majority of the tests can then be automated. Also PHPUnit does not hvae any dependencies on other software languages unlike many of the suggestions in the stackoverflow thread. With regard to the PHP version targetting, maybe we should just say (for now) 5.x Once we have test routines in place it will make it much easier to do cross version testing. For the time being, if we all try to stick to the versions of php we currently have but with Peter running the bleeding edge version, that will give a degree of cross version testability. I also agree with Peter that we should finalise a list of updates for the next release and push them out by a particular date. If we said 1st September release is our target, that would seem reasonable to me? Mark _____________________________________________ Mob: 07725 695178 Email: ma...@rw... On 10/05/2011 04:28, Peter Lazarus wrote: > The PHP support issue suggests we consider a couple of other issues. > These issues are a) some form of testing b) some feature lists and versions. > > If we are going to write and release software versions then some test > process and check-off process is needed. > > We are all working away to change things, but it is about time I think > to set some goals which we can focus on. A set of goals also allows some > software features to be released. Otherwise I feel we will be coding > until next year. If we agree on some feature based goals, without target > dates, then that gives us a way forward. The reason I said no target > dates is we are all volunteers with our lives to lead, so working toward > date targets will be difficult. > > So I suggest we compile a list of features we are working on, along with > their state of achievement. From that list we can aim to complete our > features and get them out there. I would suggest we keep our feature > list and release targets on the developer list only, and not publish it. > Then there is no pressure to get things released. > > Here is a short paper discussing some of the issues in software release > related to SubVersion 1.5. > http://www.google.com.au/url?sa=t&source=web&cd=3&ved=0CDEQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.143.4757%26rep%3Drep1%26type%3Dpdf&ei=-azITeq1BoTsuAP-ncjcBQ&usg=AFQjCNFzQFzKlcwgp24ouyLd8wl3jAiA7w > > For testing, we could use some open source web testing tools. However > these tools would require a fair bit of work to set up. Here is an > article on three of them: > http://www.infoworld.com/d/architecture/three-open-source-web-service-testing-tools-get-high-marks-995?page=0,0 > > And here are comments on even more tools: > http://stackoverflow.com/questions/79733/best-automated-testing-tool-for-web-applications > > Alternatively, we could create a simple one page list of tests that a > release needs to achieve before its release. > > 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: David T. <tom...@us...> - 2011-05-10 10:11:06
|
Peter Just to take up one of the points you make - feature lists and versions: We have used Mantis in the past, and I think it covers your wish very well. You can allocate any issue to a proposed version and manage the roadmap well. It may not be as "agile" as other tools, but I can live with that. And it demands a discipline from the developers => make sure you know on which issue you are working, and update it too. The other thing is, is that it is open and transparent. Anyone who registers can see the development status. This, I believe, is crucial to open source development. Why do you not want to publicise what we are doing? If you look through the Mantis database, there is at least one example where users have raised problems and pushed to get them resolved. How did we handle the pressure? Polite ignoring. We can handle the pressure. Everyone should accept that this is, as you say, an amateur effort, and if you need mission-critical professional support then TSNG is not the app for you. Saying that, I am a professional developer and I can send my contact details to anyone willing to pay my hourly rate :-) Mind you, if anyone needs help with 2.0, I'm not the man to hire - I haven't looked at the code in quite a while! > Date: Tue, 10 May 2011 13:28:48 +1000 > From: pal...@gm... > To: tsh...@li... > Subject: [Tsheetx-developers] Testing and target releases > > The PHP support issue suggests we consider a couple of other issues. > These issues are a) some form of testing b) some feature lists and versions. > > If we are going to write and release software versions then some test > process and check-off process is needed. > > We are all working away to change things, but it is about time I think > to set some goals which we can focus on. A set of goals also allows some > software features to be released. Otherwise I feel we will be coding > until next year. If we agree on some feature based goals, without target > dates, then that gives us a way forward. The reason I said no target > dates is we are all volunteers with our lives to lead, so working toward > date targets will be difficult. > > So I suggest we compile a list of features we are working on, along with > their state of achievement. From that list we can aim to complete our > features and get them out there. I would suggest we keep our feature > list and release targets on the developer list only, and not publish it. > Then there is no pressure to get things released. > > Here is a short paper discussing some of the issues in software release > related to SubVersion 1.5. > http://www.google.com.au/url?sa=t&source=web&cd=3&ved=0CDEQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.143.4757%26rep%3Drep1%26type%3Dpdf&ei=-azITeq1BoTsuAP-ncjcBQ&usg=AFQjCNFzQFzKlcwgp24ouyLd8wl3jAiA7w > > For testing, we could use some open source web testing tools. However > these tools would require a fair bit of work to set up. Here is an > article on three of them: > http://www.infoworld.com/d/architecture/three-open-source-web-service-testing-tools-get-high-marks-995?page=0,0 > > And here are comments on even more tools: > http://stackoverflow.com/questions/79733/best-automated-testing-tool-for-web-applications > > Alternatively, we could create a simple one page list of tests that a > release needs to achieve before its release. > > 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: Peter L. <pal...@gm...> - 2011-05-10 04:26:40
|
Hi isabelle, I have added some additional text to the language files GB and FR .ini. The additions are listed below. The changes apply to the submit times and users forms. Peter REJECT APPROVE MONTHLY_TOTAL PROJECT_TOTAL STATUS_APPROVED STATUS_OPEN STATUS_SUBMITTED SUBMIT TASK_TOTAL WEEKLY_TOTAL ACCESS ACTIVE ADD_USER ADMIN ADMINISTRATOR BASIC CONTRACTOR COPY_TASKS EMPLOYEE EMPLOYEE_TYPE FIRST_NAME LAST_NAME IS_ACTIVE LOGIN_NAME MANAGER MARK_INACTIVE PROJ_MANAGER SUPERVISOR USER_LIST |
|
From: Peter L. <pal...@gm...> - 2011-05-10 03:28:57
|
The PHP support issue suggests we consider a couple of other issues. These issues are a) some form of testing b) some feature lists and versions. If we are going to write and release software versions then some test process and check-off process is needed. We are all working away to change things, but it is about time I think to set some goals which we can focus on. A set of goals also allows some software features to be released. Otherwise I feel we will be coding until next year. If we agree on some feature based goals, without target dates, then that gives us a way forward. The reason I said no target dates is we are all volunteers with our lives to lead, so working toward date targets will be difficult. So I suggest we compile a list of features we are working on, along with their state of achievement. From that list we can aim to complete our features and get them out there. I would suggest we keep our feature list and release targets on the developer list only, and not publish it. Then there is no pressure to get things released. Here is a short paper discussing some of the issues in software release related to SubVersion 1.5. http://www.google.com.au/url?sa=t&source=web&cd=3&ved=0CDEQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.143.4757%26rep%3Drep1%26type%3Dpdf&ei=-azITeq1BoTsuAP-ncjcBQ&usg=AFQjCNFzQFzKlcwgp24ouyLd8wl3jAiA7w For testing, we could use some open source web testing tools. However these tools would require a fair bit of work to set up. Here is an article on three of them: http://www.infoworld.com/d/architecture/three-open-source-web-service-testing-tools-get-high-marks-995?page=0,0 And here are comments on even more tools: http://stackoverflow.com/questions/79733/best-automated-testing-tool-for-web-applications Alternatively, we could create a simple one page list of tests that a release needs to achieve before its release. Peter |
|
From: Peter L. <pal...@gm...> - 2011-05-09 22:57:52
|
I think this is a difficult issue. Looking at it from what software I run and the platform I develop on, I keep my Fedora system up to date at least every six months and often more frequently. So the code I test is against a fairly recent version of PHP which is probably not installed much worldwide. We are a bunch of amateur developers, and I mean that in the nicest possible way. Whatever platform we have at home, is what we develop on and test against. If we are to have a set range of supported PHP levels, then we have to become a bunch of organised amateur developers. That means we will have to maintain a few levels of PHP on our systems to test TSNG against. That testing could take place on a planned release of TSNG I think, following a release plan agreed by all. Peter On 05/09/2011 06:05 PM, David Thompson wrote: > We've had this kind of problem in the past, and I think will have it > in the future too. > Two years ago it was the move from PHP v4 to v5, but now v5.1, v5.2 > and v5.3 all seem to have significant differences (in their libraries). > > The problem is that PHP is faster than we are, but we could use that > to our advantage. > Previously I proposed "mainstream", ie support the PHP version that > comes as standard with the main linux distros (was 5.2, but I think is > now 5.3). > > But maybe we should now go "bleeding-edge" and set 5.3 as a minimum. > It would avoid problems in development, and by the time we release it > should be mainstream. > > What's your experience? > > Tommo > |
|
From: Scott M. <Sco...@pr...> - 2011-05-09 14:00:10
|
By targeting bleeding edge, you risk two things: Alienating many users who may be unable to support bleeding edge on the server(s) they currently use to run the timesheet system slipping release dates because PHP keeps changing under you There are only a few areas of PHP that have significantly changed from 5.1 to whatever they're at today. I would strongly recommend supporting 5.x by either not using bleeding edge features of the language, or by offering alternative ways of accomplishing those things to the versions that didn't support those features. The right thing to do, is very often not the easy thing to do. -Scott ________________________________ From: David Thompson [mailto:tom...@us...] Sent: Monday, May 09, 2011 3:05 AM To: tsh...@li... Subject: Re: [Tsheetx-developers] Language switch We've had this kind of problem in the past, and I think will have it in the future too. Two years ago it was the move from PHP v4 to v5, but now v5.1, v5.2 and v5.3 all seem to have significant differences (in their libraries). The problem is that PHP is faster than we are, but we could use that to our advantage. Previously I proposed "mainstream", ie support the PHP version that comes as standard with the main linux distros (was 5.2, but I think is now 5.3). But maybe we should now go "bleeding-edge" and set 5.3 as a minimum. It would avoid problems in development, and by the time we release it should be mainstream. What's your experience? Tommo > Date: Fri, 6 May 2011 09:08:07 -0500 > From: Sco...@pr... > To: ma...@rw...; tsh...@li... > Subject: Re: [Tsheetx-developers] Language switch > > I'm running 5.1.6; you're probably remembering that <wrong>I was hoping > to be able to support php 4.x with our next release.</wrong> I'm > thinking I didn't have any instances of that left to test against (and > very likely won't at the new employer either). > > Scratch that now I'm getting a memory back that there was some major > change in the 5.x versions where new the json serialization routines > suddenly made an appearance and the code didn't work with less than > (guessing here) 5.3 or some such, and I wanted to ensure support for php > 5.1.x in the next release. > > -Scott > > -----Original Message----- > From: Mark Wrightson [mailto:ma...@rw...] > Sent: Friday, May 06, 2011 6:18 AM > To: tsh...@li... > Subject: Re: [Tsheetx-developers] Language switch > > I am running PHP V5.3.2 and I now get jLogin, jLogout with the correct > case. :) > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 06/05/2011 05:05, Peter Lazarus wrote: > > Isabelle, > > I wonder what version of php your server is using. If it is earlier > than > > 5.3.0, you would not experience any problem. From memory, Scott has > php > > version 4.something. > > > > My version of php is 5.3.6 and I did have a problem with language, no > > language strings were displayed. > > Peter > > > > On 05/05/2011 04:18 PM, Isabelle Vergely wrote: > >> Hi all, > >> > >> I am surprised because I have no problem with the language switch. > >> I applied what said Scott in a message sent to the list > >> (2011-03-30 15:53), see: > >> http://sourceforge.net/mailarchive/message.php?msg_id=27283175 > >> > >> To test the language, in the file: include/jclasses/factory.php > >> change the line (#74): > >> $locale = "en-GB"; > >> For me, having $locale = "en-GB" or $locale = "fr-FR", it's OK > >> to display strings respectively in English or French. > >> > >> I haven't test the last modification made be Peter yesterday. > >> I will look to this soon. > >> > >> Isabelle. > >> > >> > ------------------------------------------------------------------------ > ------ > >> WhatsUp Gold - Download Free Network Management Software > >> The most intuitive, comprehensive, and cost-effective network > >> management toolset available today. Delivers lowest initial > >> acquisition cost and overall TCO of any competing solution. > >> http://p.sf.net/sfu/whatsupgold-sd > >> _______________________________________________ > >> Tsheetx-developers mailing list > >> Tsh...@li... > >> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > >> > > > ------------------------------------------------------------------------ > ------ > > WhatsUp Gold - Download Free Network Management Software > > The most intuitive, comprehensive, and cost-effective network > > management toolset available today. Delivers lowest initial > > acquisition cost and overall TCO of any competing solution. > > http://p.sf.net/sfu/whatsupgold-sd > > _______________________________________________ > > Tsheetx-developers mailing list > > Tsh...@li... > > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > > ------------------------------------------------------------------------ > ------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > ------------------------------------------------------------------------ ------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
|
From: David T. <tom...@us...> - 2011-05-09 08:05:38
|
We've had this kind of problem in the past, and I think will have it in the future too. Two years ago it was the move from PHP v4 to v5, but now v5.1, v5.2 and v5.3 all seem to have significant differences (in their libraries). The problem is that PHP is faster than we are, but we could use that to our advantage. Previously I proposed "mainstream", ie support the PHP version that comes as standard with the main linux distros (was 5.2, but I think is now 5.3). But maybe we should now go "bleeding-edge" and set 5.3 as a minimum. It would avoid problems in development, and by the time we release it should be mainstream. What's your experience? Tommo > Date: Fri, 6 May 2011 09:08:07 -0500 > From: Sco...@pr... > To: ma...@rw...; tsh...@li... > Subject: Re: [Tsheetx-developers] Language switch > > I'm running 5.1.6; you're probably remembering that <wrong>I was hoping > to be able to support php 4.x with our next release.</wrong> I'm > thinking I didn't have any instances of that left to test against (and > very likely won't at the new employer either). > > Scratch that now I'm getting a memory back that there was some major > change in the 5.x versions where new the json serialization routines > suddenly made an appearance and the code didn't work with less than > (guessing here) 5.3 or some such, and I wanted to ensure support for php > 5.1.x in the next release. > > -Scott > > -----Original Message----- > From: Mark Wrightson [mailto:ma...@rw...] > Sent: Friday, May 06, 2011 6:18 AM > To: tsh...@li... > Subject: Re: [Tsheetx-developers] Language switch > > I am running PHP V5.3.2 and I now get jLogin, jLogout with the correct > case. :) > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 06/05/2011 05:05, Peter Lazarus wrote: > > Isabelle, > > I wonder what version of php your server is using. If it is earlier > than > > 5.3.0, you would not experience any problem. From memory, Scott has > php > > version 4.something. > > > > My version of php is 5.3.6 and I did have a problem with language, no > > language strings were displayed. > > Peter > > > > On 05/05/2011 04:18 PM, Isabelle Vergely wrote: > >> Hi all, > >> > >> I am surprised because I have no problem with the language switch. > >> I applied what said Scott in a message sent to the list > >> (2011-03-30 15:53), see: > >> http://sourceforge.net/mailarchive/message.php?msg_id=27283175 > >> > >> To test the language, in the file: include/jclasses/factory.php > >> change the line (#74): > >> $locale = "en-GB"; > >> For me, having $locale = "en-GB" or $locale = "fr-FR", it's OK > >> to display strings respectively in English or French. > >> > >> I haven't test the last modification made be Peter yesterday. > >> I will look to this soon. > >> > >> Isabelle. > >> > >> > ------------------------------------------------------------------------ > ------ > >> WhatsUp Gold - Download Free Network Management Software > >> The most intuitive, comprehensive, and cost-effective network > >> management toolset available today. Delivers lowest initial > >> acquisition cost and overall TCO of any competing solution. > >> http://p.sf.net/sfu/whatsupgold-sd > >> _______________________________________________ > >> Tsheetx-developers mailing list > >> Tsh...@li... > >> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > >> > > > ------------------------------------------------------------------------ > ------ > > WhatsUp Gold - Download Free Network Management Software > > The most intuitive, comprehensive, and cost-effective network > > management toolset available today. Delivers lowest initial > > acquisition cost and overall TCO of any competing solution. > > http://p.sf.net/sfu/whatsupgold-sd > > _______________________________________________ > > Tsheetx-developers mailing list > > Tsh...@li... > > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > > ------------------------------------------------------------------------ > ------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
|
From: Scott M. <Sco...@pr...> - 2011-05-06 15:08:42
|
I'm running 5.1.6; you're probably remembering that <wrong>I was hoping to be able to support php 4.x with our next release.</wrong> I'm thinking I didn't have any instances of that left to test against (and very likely won't at the new employer either). Scratch that now I'm getting a memory back that there was some major change in the 5.x versions where new the json serialization routines suddenly made an appearance and the code didn't work with less than (guessing here) 5.3 or some such, and I wanted to ensure support for php 5.1.x in the next release. -Scott -----Original Message----- From: Mark Wrightson [mailto:ma...@rw...] Sent: Friday, May 06, 2011 6:18 AM To: tsh...@li... Subject: Re: [Tsheetx-developers] Language switch I am running PHP V5.3.2 and I now get jLogin, jLogout with the correct case. :) _____________________________________________ Mob: 07725 695178 Email: ma...@rw... On 06/05/2011 05:05, Peter Lazarus wrote: > Isabelle, > I wonder what version of php your server is using. If it is earlier than > 5.3.0, you would not experience any problem. From memory, Scott has php > version 4.something. > > My version of php is 5.3.6 and I did have a problem with language, no > language strings were displayed. > Peter > > On 05/05/2011 04:18 PM, Isabelle Vergely wrote: >> Hi all, >> >> I am surprised because I have no problem with the language switch. >> I applied what said Scott in a message sent to the list >> (2011-03-30 15:53), see: >> http://sourceforge.net/mailarchive/message.php?msg_id=27283175 >> >> To test the language, in the file: include/jclasses/factory.php >> change the line (#74): >> $locale = "en-GB"; >> For me, having $locale = "en-GB" or $locale = "fr-FR", it's OK >> to display strings respectively in English or French. >> >> I haven't test the last modification made be Peter yesterday. >> I will look to this soon. >> >> Isabelle. >> >> ------------------------------------------------------------------------ ------ >> WhatsUp Gold - Download Free Network Management Software >> The most intuitive, comprehensive, and cost-effective network >> management toolset available today. Delivers lowest initial >> acquisition cost and overall TCO of any competing solution. >> http://p.sf.net/sfu/whatsupgold-sd >> _______________________________________________ >> Tsheetx-developers mailing list >> Tsh...@li... >> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers >> > ------------------------------------------------------------------------ ------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > ------------------------------------------------------------------------ ------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
29 messages has been excluded from this view by a project administrator.
