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: Mark W. <ma...@rw...> - 2011-04-15 21:10:38
|
<!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">
Hi Scott, <br>
<br>
I was thinking a little bit about this yesterday as I spent a
substantial amount of time fixing the $post variables. As it
currently stands, the $post variable is now in the gbl.class.php and
is accessed via gbl::getPost() and gbl::setPost(). Please let me
know if a particular page doesn't work as it should. <br>
<br>
If you want to maintain state between page refreshes then the best
way to achieve this is through the use of the $_SESSION object or
serialised classes embedded in the $_SESSION object. I will update
this at somepoint but at the moment I am still trying to work my way
through the codebase to make things just work. The move to the OO
format is a huge undertaking and it is not really my top priority at
the moment as I have a project dissertation that needs my attention
for the next couple of months. Scott could you add this item into
mantis and assign it to me?<br>
<br>
Cheers<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 15/04/2011 21:04, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">In the previous versions of TSNG, I'd attempted to
better keep track of what "context" the user was in. I'd
accomplished this by making use of a variable I'd called $post,
and used that whenever forms were submitted. This was much better
than it was previously, but it was not flawless by any stretch of
the imagination.<br>
<br>
So, to help make sure everyone understands what I'm talking about,
allow me to expound on what the word "context" means herein.
Context is sort of the "state of mind" the user is in when trying
to accomplish something. As a normal user, if I go back in time
to look at something lets say in the weekly form, and then decide
I want to look at that with a different form, say the monthly
form, in previous versions, by switching forms, the application
totally forgot the user had gone back in time, and presented the
current month again. By keeping track of context, the user is now
presented with the month the user had gone back to look at. This
is one very basic and important item of context that I think we
need to keep track of, what date is the user currently interested
in?<br>
<br>
Another example is if I'm now an administrator, and a user has
some problem with their previously entered time, I can "become"
the user by changing the "context user" and from there, I can act
as if I was the user and I can even modify the user's time entries
if I need to do so. (Note: this option is only available to the
"administrator" accounts, and to guard against unscrupulous
managers, who might be tempted to fraudulently modify an
underling's times, never make a manager an administrator. It is
quite amazing in a tiny office how often we as administrators had
to legitimately help fix someone's time entries).<br>
<br>
So far we have <br>
<ul>
<li>Context</li>
<ul>
<li>user id</li>
<li>date user is interested in</li>
</ul>
</ul>
We can add other items; if we're looking at a report and we are
interested in a range of dates for a report, we need to keep track
of the beginning and ending date of interest. With new options
just created, another item might be if we want page areas shown or
hidden.<br>
<br>
So, with all this, my main question to the group is how do we
effectively keep track of all this potential context? With Mark
as the OO guy, I'm hoping you have some good ideas for helping us
keep track of it all, and I'm hoping that option is better than
the hugely long set of post variables currently passed back and
forth. This is particularly important when we move to using the
java pop up calendar for navigation...<br>
<br>
-Scott<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-04-15 20:04:11
|
In the previous versions of TSNG, I'd attempted to better keep track of what
"context" the user was in. I'd accomplished this by making use of a
variable I'd called $post, and used that whenever forms were submitted.
This was much better than it was previously, but it was not flawless by any
stretch of the imagination.
So, to help make sure everyone understands what I'm talking about, allow me
to expound on what the word "context" means herein. Context is sort of the
"state of mind" the user is in when trying to accomplish something. As a
normal user, if I go back in time to look at something lets say in the
weekly form, and then decide I want to look at that with a different form,
say the monthly form, in previous versions, by switching forms, the
application totally forgot the user had gone back in time, and presented the
current month again. By keeping track of context, the user is now presented
with the month the user had gone back to look at. This is one very basic
and important item of context that I think we need to keep track of, what
date is the user currently interested in?
Another example is if I'm now an administrator, and a user has some problem
with their previously entered time, I can "become" the user by changing the
"context user" and from there, I can act as if I was the user and I can even
modify the user's time entries if I need to do so. (Note: this option is
only available to the "administrator" accounts, and to guard against
unscrupulous managers, who might be tempted to fraudulently modify an
underling's times, never make a manager an administrator. It is quite
amazing in a tiny office how often we as administrators had to legitimately
help fix someone's time entries).
So far we have
- Context
- user id
- date user is interested in
We can add other items; if we're looking at a report and we are interested
in a range of dates for a report, we need to keep track of the beginning and
ending date of interest. With new options just created, another item might
be if we want page areas shown or hidden.
So, with all this, my main question to the group is how do we effectively
keep track of all this potential context? With Mark as the OO guy, I'm
hoping you have some good ideas for helping us keep track of it all, and I'm
hoping that option is better than the hugely long set of post variables
currently passed back and forth. This is particularly important when we
move to using the java pop up calendar for navigation...
-Scott
|
|
From: Scott M. <sco...@gm...> - 2011-04-15 19:35:54
|
Hey Mark,
You've done lots of work there. Yes, the java stuff does all appear to work
now with your new code. When I was debugging things, the java loaded, but
couldn't see any of the variables that php had setup, so putting them back
together seemed to fix the problem from me. So long as it's all working
again the way it's supposed to, I'm happy.
I kinda like the "show / hide calendar" thing, but if we can get the java
pop up calendar thing to function so the user doesn't have to click as much
to get the "context date" to change, I'm willing to let the old calendar
navigation go away.
I've got one pet peeve that apparently you are responsible for tickling:
Could I request that you stop splitting the else from the end bracket? ie.
I like seeing this:
if (something) {
do this
} else {
do that
}
And you like to have this changed to this:
if (something) {
do this
}
else {
do that
}
To me, the else block is closely related to the previous if, and by
splitting it off like you do, I think it makes it look more like a
potentially unrelated block.
-Scott
On Thu, Apr 14, 2011 at 11:32 PM, Mark Wrightson
<ma...@rw...>wrote:
> Hi,
>
> I have spent quite some time working to remove some of the global
> variables that of course no longer work.
> Whilst working through this process it has meant I have been tidying up
> various pieces of code and in some cases
> rewriting sections to ensure that things work properly rather than
> magically.
>
> Part of this process is to remove include files that are not classes.
> For instance in stopwatch:
>
> Before:
> //$stopwatch = 1;
> //$fromPopup = "true";
> //include(dirname(__FILE__)."/../include/tsx/clockOnOff_core_new.inc");
>
> After:
> require("include/tsx/clocking.class.php");
> $clock = new Clocking();
> $clock->createClockOnOff(null,true,false,true);
>
> by doing this the variables can be traced through and if a variable
> isn't passed into a function it will cause an error
> whereas it was hit and miss before. This is still an on going process.
>
> I have created classes for the stopwatch clock and also navcal.
>
> Please be aware that I still haven't finished making the stopwatch work.
>
> All the stopwatches and navcals have show hide functionality built in to
> tidy up the pages. I realise that some of the work that is done here is
> stuff that is being slowly modified / replaced but it really was
> necessary in my aim to clean up the codebase!
>
> Scott:
> I noticed that you changed a line in client_proj_task_javascript.php
> that caused the stopwatch js to stop working:
>
> <script type="text/javascript" src="<?php echo
> Config::getRelativeRoot();?>/js/client_proj_task_javascript.js"></script>
>
> to
> include(...client_proj_task_javascript.js...)
>
> The note you left in the code about variables that could not be accessed
> outside of a js script is as far as i'm aware incorrect.
> A variable in the global namespace in javascript, be it assigned inline
> on a html page or outside of a function in a js file, are all accessible
> from anywhere. I think the exact reason why the code didn't work was a
> missing quotation mark in the <script> line above. Please can you
> confirm that the drop down boxes in stopwatch now function again on your
> setup?
>
> When I rewrote the js code for stopwatch several months ago, my aim was
> to remove all php code from the javascript files and getting all the
> large js chunks into an external file rather than cluttering up the head
> of each html page. This is why I created the
> client_proj_task_javascript.class.php file so that this could be achieved.
>
> Regards
> Mark
>
> --
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
|
|
From: Mark W. <ma...@rw...> - 2011-04-14 23:32:41
|
Hi,
I have spent quite some time working to remove some of the global
variables that of course no longer work.
Whilst working through this process it has meant I have been tidying up
various pieces of code and in some cases
rewriting sections to ensure that things work properly rather than
magically.
Part of this process is to remove include files that are not classes.
For instance in stopwatch:
Before:
//$stopwatch = 1;
//$fromPopup = "true";
//include(dirname(__FILE__)."/../include/tsx/clockOnOff_core_new.inc");
After:
require("include/tsx/clocking.class.php");
$clock = new Clocking();
$clock->createClockOnOff(null,true,false,true);
by doing this the variables can be traced through and if a variable
isn't passed into a function it will cause an error
whereas it was hit and miss before. This is still an on going process.
I have created classes for the stopwatch clock and also navcal.
Please be aware that I still haven't finished making the stopwatch work.
All the stopwatches and navcals have show hide functionality built in to
tidy up the pages. I realise that some of the work that is done here is
stuff that is being slowly modified / replaced but it really was
necessary in my aim to clean up the codebase!
Scott:
I noticed that you changed a line in client_proj_task_javascript.php
that caused the stopwatch js to stop working:
<script type="text/javascript" src="<?php echo
Config::getRelativeRoot();?>/js/client_proj_task_javascript.js"></script>
to
include(...client_proj_task_javascript.js...)
The note you left in the code about variables that could not be accessed
outside of a js script is as far as i'm aware incorrect.
A variable in the global namespace in javascript, be it assigned inline
on a html page or outside of a function in a js file, are all accessible
from anywhere. I think the exact reason why the code didn't work was a
missing quotation mark in the <script> line above. Please can you
confirm that the drop down boxes in stopwatch now function again on your
setup?
When I rewrote the js code for stopwatch several months ago, my aim was
to remove all php code from the javascript files and getting all the
large js chunks into an external file rather than cluttering up the head
of each html page. This is why I created the
client_proj_task_javascript.class.php file so that this could be achieved.
Regards
Mark
--
_____________________________________________
Mob: 07725 695178
Email: ma...@rw...
|
|
From: Scott M. <sco...@gm...> - 2011-04-14 14:57:56
|
The all caps just mean that nothing has been put into the translation files yet. And the bizzare date format, I've seen that before, but I don't remember why or how I fixed it. I'm not really buying into the "oh, we need to protect the users from themselves" argument, but this could perhaps be a user configurable item (once we actually get a working user configuration area). I think you're over reacting to the amount of data being posted. I realize change is sometimes disconcerting, so, play with it as we develop it, and I think you'll see you're perhaps just trying to cling to something that is familiar to you now. -Scott On Thu, Apr 14, 2011 at 2:37 PM, Mark Wrightson <ma...@rw...>wrote: > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 14/04/2011 15:20, Scott Miller wrote: > > <grin> I thought it might make more sense once you saw what I had in mind. > > Yes, the ability to edit multiple entries was part of my plan. Considering > we should have potentially more data being passed in via the simple sheet, I > think as long as your max_post_size is set to something sane, 64K or more, I > don't think you'll run into any problems even with your habit of entering an > entire paragraph for each task :-). I would rather not have to keep the > edit screen around if we don't need it. Yes, I want to put a date field in > there somehow. > > I don't particularly like that you could accidentally edit something. i.e. > if you have 10 clocks on the newdaily page, you could quite easily type into > the wrong box or something (user error i know). This could be tidied up if > there was a button next to delete called edit that then enabled that row for > editting using javascript. Thus a user has to intentionally do something to > edit a clock. Also it would mean only the changed rows (the rows being > editted) would require submission, thus reducing the number of items being > transmitted back to the server. The button could be a check box? > > > Would it be better/simpler to have drop down selects for each date item > (day, month, year)? Or should we use the date picker? > > I think the date picker would be better. The date picker does need some > work doing it to improve it, but on the whole I think it is a better way of > doing things. > I think we should have separate fields for date and time as per google > calendars as it makes it easier to work with and is more clean. > > > Considering the layout is selectable, and you're the one that last made > changes to the "big description" layout (as copied from the simple.php > file), you should be able to tweak the vertical spaces as you'd like (at > least I'm assuming you're talking about vertical space when you mentioned > finding it hard to click on the correct drop down menu). > > Oh right, I see. Multiple different layouts are present. I think that the > "no description" view should be scrapped. Clock times have no meaning > unless something descriptive is written next to them when you are looking > back after even just one week. > > > A collaborative effort on this would be great Mark, Peter, others, so > change/fix things and check them in, but please notify us when you've > checked in your stuff. > > Can we do something about the english translations all in capital letters > / no spaces as it is quite annoying. i.e. > > " JDAILY: 14ThuAprilAprCEST_Apr+02004CEST00_ThuAM2011_2011EAMR"? > > Cheers > Mark > > -Scott > > On Thu, Apr 14, 2011 at 10:12 AM, Mark Wrightson <ma...@rw... > > wrote: > >> Hi Scott, >> >> I thought from your original description that the work you were doing was >> a replacement of just the clock on/off box. It makes more sense now! >> >> One problem I can foresee is that whenever you submit a new clock, it will >> also submit all other clocks on this page, and we may run into the post size >> limit. This could easily be avoided by only submitting individual clock >> times. Can we implement your idea in such a way that clock times that >> already have been entered do not appear in form fields? An edit button >> could be added and a bit of javascript used to enable editting of that >> particular clock time. This style of implementation would then lend itself >> to the scenario when times have already been 'submitted to a supervisor' and >> aren't available for editting. >> >> Do you intend to add a date field into this form, particularly in the end >> time so that clocking over a day boundary can be supported? The javascript >> date picker can be configured to add time entry on the bottom aswell just so >> you know. >> >> The clock on/off buttons could be in the same column to save space in >> width (one above the other)? >> I realise this is just a preliminary version, but i find it is very easy >> to click on the wrong drop down menu, I think that some more space between >> each one is required. >> Also rather than creating a new row when the task field has been selected, >> maybe there could be a add a new clock button instead? >> >> >> >> Cheers >> Mark >> >> _____________________________________________ >> >> Mob: 07725 695178 >> Email: ma...@rw... >> >> >> On 14/04/2011 04:42, Peter Lazarus wrote: >> >> Well I like it. It covers all that is in the daily sheet and removes the >> clockon/off thing above. That results in a neater looking entry form. The >> clock on now clock off now columns will become the green/red buttons I >> assume. >> Peter >> >> On 04/14/2011 08:14 AM, Scott Miller wrote: >> >> I've just submitted my updates, and I've added a very rough page called >> newdaily. The submission script doesn't exist, the grand total doesn't >> calculate the right thing, but the rough concept is there, take a look and >> see what you think. >> >> -Scott >> >> On Wed, Apr 13, 2011 at 9:08 PM, Mark Wrightson <ma...@rw... >> > wrote: >> >>> Hey Everyone, >>> >>> Please could you do a SVN Update, I have gone through and corrected all >>> of the db table references in every file. >>> >>> Cheers Mark >>> >>> -- >>> _____________________________________________ >>> >>> Mob: 07725 695178 >>> Email: ma...@rw... >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and >>> improve >>> application availability and disaster protection. Learn more about >>> boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Tsheetx-developers mailing list >>> Tsh...@li... >>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers >>> >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> >> >> _______________________________________________ >> Tsheetx-developers mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tsheetx-developers >> >> > |
|
From: Mark W. <ma...@rw...> - 2011-04-14 14:37:13
|
<!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">
<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 14/04/2011 15:20, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite"><grin> I thought it might make more sense once
you saw what I had in mind.<br>
<br>
Yes, the ability to edit multiple entries was part of my plan.
Considering we should have potentially more data being passed in
via the simple sheet, I think as long as your max_post_size is set
to something sane, 64K or more, I don't think you'll run into any
problems even with your habit of entering an entire paragraph for
each task :-). I would rather not have to keep the edit screen
around if we don't need it. Yes, I want to put a date field in
there somehow.<br>
<br>
</blockquote>
I don't particularly like that you could accidentally edit
something. i.e. if you have 10 clocks on the newdaily page, you
could quite easily type into the wrong box or something (user error
i know). This could be tidied up if there was a button next to
delete called edit that then enabled that row for editting using
javascript. Thus a user has to intentionally do something to edit a
clock. Also it would mean only the changed rows (the rows being
editted) would require submission, thus reducing the number of items
being transmitted back to the server. The button could be a check
box?<br>
<br>
<blockquote
cite="mid:BAN...@ma..."
type="cite">Would it be better/simpler to have drop down selects
for each date item (day, month, year)? Or should we use the date
picker?<br>
</blockquote>
I think the date picker would be better. The date picker does need
some work doing it to improve it, but on the whole I think it is a
better way of doing things.<br>
I think we should have separate fields for date and time as per
google calendars as it makes it easier to work with and is more
clean.<br>
<blockquote
cite="mid:BAN...@ma..."
type="cite"><br>
Considering the layout is selectable, and you're the one that last
made changes to the "big description" layout (as copied from the
simple.php file), you should be able to tweak the vertical spaces
as you'd like (at least I'm assuming you're talking about vertical
space when you mentioned finding it hard to click on the correct
drop down menu).<br>
</blockquote>
Oh right, I see. Multiple different layouts are present. I think
that the "no description" view should be scrapped. Clock times have
no meaning unless something descriptive is written next to them when
you are looking back after even just one week.<br>
<blockquote
cite="mid:BAN...@ma..."
type="cite">
<br>
A collaborative effort on this would be great Mark, Peter, others,
so change/fix things and check them in, but please notify us when
you've checked in your stuff.<br>
<br>
</blockquote>
Can we do something about the english translations all in capital
letters / no spaces as it is quite annoying. i.e.<br>
<br>
" JDAILY: 14ThuAprilAprCEST_Apr+02004CEST00_ThuAM2011_2011EAMR"?<br>
<br>
Cheers<br>
Mark<br>
<blockquote
cite="mid:BAN...@ma..."
type="cite">-Scott<br>
<br>
<div class="gmail_quote">On Thu, Apr 14, 2011 at 10:12 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"> Hi Scott, <br>
<br>
I thought from your original description that the work you
were doing was a replacement of just the clock on/off box.
It makes more sense now! <br>
<br>
One problem I can foresee is that whenever you submit a new
clock, it will also submit all other clocks on this page,
and we may run into the post size limit. This could easily
be avoided by only submitting individual clock times. Can
we implement your idea in such a way that clock times that
already have been entered do not appear in form fields? An
edit button could be added and a bit of javascript used to
enable editting of that particular clock time. This style
of implementation would then lend itself to the scenario
when times have already been 'submitted to a supervisor' and
aren't available for editting.<br>
<br>
Do you intend to add a date field into this form,
particularly in the end time so that clocking over a day
boundary can be supported? The javascript date picker can
be configured to add time entry on the bottom aswell just so
you know.<br>
<br>
The clock on/off buttons could be in the same column to save
space in width (one above the other)?<br>
I realise this is just a preliminary version, but i find it
is very easy to click on the wrong drop down menu, I think
that some more space between each one is required.<br>
Also rather than creating a new row when the task field has
been selected, maybe there could be a add a new clock button
instead?
<div class="im"><br>
<br>
<br>
Cheers<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>
<br>
</div>
<div>
<div class="h5"> On 14/04/2011 04:42, Peter Lazarus wrote:
<blockquote type="cite"> Well I like it. It covers all
that is in the daily sheet and removes the clockon/off
thing above. That results in a neater looking entry
form. The clock on now clock off now columns will
become the green/red buttons I assume.<br>
Peter <br>
<br>
On 04/14/2011 08:14 AM, Scott Miller wrote:
<blockquote type="cite">I've just submitted my
updates, and I've added a very rough page called
newdaily. The submission script doesn't exist, the
grand total doesn't calculate the right thing, but
the rough concept is there, take a look and see what
you think.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Wed, Apr 13, 2011 at
9:08 PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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;"> Hey Everyone,<br>
<br>
Please could you do a SVN Update, I have gone
through and corrected all<br>
of the db table references in every file.<br>
<br>
Cheers Mark<br>
<br>
--<br>
_____________________________________________<br>
<br>
Mob: <a moz-do-not-send="true"
href="tel:07725%20695178" value="+17725695178"
target="_blank">07725 695178</a><br>
Email: <a moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Benefiting from Server Virtualization: Beyond
Initial Workload<br>
Consolidation -- Increasing the use of server
virtualization is a top<br>
priority.Virtualization can reduce costs,
simplify management, and improve<br>
application availability and disaster
protection. Learn more about boosting<br>
the value of server virtualization. <a
moz-do-not-send="true"
href="http://p.sf.net/sfu/vmware-sfdev2dev"
target="_blank">http://p.sf.net/sfu/vmware-sfdev2dev</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>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. <a moz-do-not-send="true" href="http://p.sf.net/sfu/vmware-sfdev2dev" target="_blank">http://p.sf.net/sfu/vmware-sfdev2dev</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>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-04-14 14:20:54
|
<grin> I thought it might make more sense once you saw what I had in mind. Yes, the ability to edit multiple entries was part of my plan. Considering we should have potentially more data being passed in via the simple sheet, I think as long as your max_post_size is set to something sane, 64K or more, I don't think you'll run into any problems even with your habit of entering an entire paragraph for each task :-). I would rather not have to keep the edit screen around if we don't need it. Yes, I want to put a date field in there somehow. Would it be better/simpler to have drop down selects for each date item (day, month, year)? Or should we use the date picker? Considering the layout is selectable, and you're the one that last made changes to the "big description" layout (as copied from the simple.php file), you should be able to tweak the vertical spaces as you'd like (at least I'm assuming you're talking about vertical space when you mentioned finding it hard to click on the correct drop down menu). A collaborative effort on this would be great Mark, Peter, others, so change/fix things and check them in, but please notify us when you've checked in your stuff. -Scott On Thu, Apr 14, 2011 at 10:12 AM, Mark Wrightson <ma...@rw...>wrote: > Hi Scott, > > I thought from your original description that the work you were doing was a > replacement of just the clock on/off box. It makes more sense now! > > One problem I can foresee is that whenever you submit a new clock, it will > also submit all other clocks on this page, and we may run into the post size > limit. This could easily be avoided by only submitting individual clock > times. Can we implement your idea in such a way that clock times that > already have been entered do not appear in form fields? An edit button > could be added and a bit of javascript used to enable editting of that > particular clock time. This style of implementation would then lend itself > to the scenario when times have already been 'submitted to a supervisor' and > aren't available for editting. > > Do you intend to add a date field into this form, particularly in the end > time so that clocking over a day boundary can be supported? The javascript > date picker can be configured to add time entry on the bottom aswell just so > you know. > > The clock on/off buttons could be in the same column to save space in width > (one above the other)? > I realise this is just a preliminary version, but i find it is very easy to > click on the wrong drop down menu, I think that some more space between each > one is required. > Also rather than creating a new row when the task field has been selected, > maybe there could be a add a new clock button instead? > > > > Cheers > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 14/04/2011 04:42, Peter Lazarus wrote: > > Well I like it. It covers all that is in the daily sheet and removes the > clockon/off thing above. That results in a neater looking entry form. The > clock on now clock off now columns will become the green/red buttons I > assume. > Peter > > On 04/14/2011 08:14 AM, Scott Miller wrote: > > I've just submitted my updates, and I've added a very rough page called > newdaily. The submission script doesn't exist, the grand total doesn't > calculate the right thing, but the rough concept is there, take a look and > see what you think. > > -Scott > > On Wed, Apr 13, 2011 at 9:08 PM, Mark Wrightson <ma...@rw...>wrote: > >> Hey Everyone, >> >> Please could you do a SVN Update, I have gone through and corrected all >> of the db table references in every file. >> >> Cheers Mark >> >> -- >> _____________________________________________ >> >> Mob: 07725 695178 >> Email: ma...@rw... >> >> >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about >> boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Tsheetx-developers mailing list >> Tsh...@li... >> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers >> > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > > _______________________________________________ > Tsheetx-developers mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
|
From: Scott M. <sco...@gm...> - 2011-04-14 13:50:21
|
Ah, good, so those will be useful! I had begun to think those language entries would not be needed because I thought they would be handled correctly by the date functions and the setlocale stuff. -Scott On Thu, Apr 14, 2011 at 10:13 AM, Isabelle Vergely <ver...@fr... > wrote: > For days and months with accented letters, the solution is probably using > something similar to functions in the file: > Joomla/libraries/joomla/utilities/date.php: > _monthToString and _dayToString functions uses the JText::_ function to > correctly display these data. > Months and days are already defined in language files. > > Isabelle. > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > |
|
From: Mark W. <ma...@rw...> - 2011-04-14 10:14:02
|
<!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">
Hi peter, <br>
<br>
Yes you are right about the mobile css type, however a large (wide)
table will always need a large amount of screen space and no level
of css will ever be able to change that.<br>
<br>
Cheers<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 14/04/2011 04:49, Peter Lazarus wrote:
<blockquote cite="mid:4DA...@gm..." type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Mobile devices are handled by a separate css style sheet. The link
to that style sheet contains: <big><big><code>media="handheld</code></big></big><br>
Have a look here for an introduction.
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://perishablepress.com/press/2009/08/02/the-5-minute-css-mobile-makeover/">http://perishablepress.com/press/2009/08/02/the-5-minute-css-mobile-makeover/</a><br>
<br>
Just another good reason to clean up the html and drive the
formatting via css. Sigh, I continue to pick away at the styles
in tsng.<br>
<br>
On 04/13/2011 11:49 PM, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite"><br>
<br>
<div class="gmail_quote">---------- Forwarded message ----------<br>
From: <b class="gmail_sendername">Scott Miller</b> <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm...">sco...@gm...</a>></span><br>
Date: Wed, Apr 13, 2011 at 1:45 PM<br>
Subject: Re: [Tsheetx-developers] txsheet-2.0-demo: new commit
for internationalization<br>
To: Mark Wrightson <<a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a>><br>
<br>
<br>
Ah, I was not thinking about "mobile devices", so I saw no
point in stretching things vertically.<br>
<br>
We could perhaps make two layouts, one for normal screens and
another for mobile devices, is there an easy way to tell if a
mobile device is viewing the page?<br>
<br>
The current version uses a 'text' field in the database which
can hold up to 65535 characters, ie. 64kb. I'm fairly certain
(but haven't verified) there is nothing in the code that cares
how long a text message is, but it could be affected by the
php max_post_size limitation.<br>
<font color="#888888"> <br>
-Scott</font>
<div>
<div class="h5"><br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 10:26 PM,
Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> The way the
current clocking form is, it is suitable for use on
small screens i.e. a smart phone which is a good
feature.<br>
The simple.php doesn't work well on a small screen
due to width. Extended descriptions with carriage
returns aren't possible either in simple.php whereas
the other clocking methods allowed for carriage
returns due to the use of textareas instead of
single row fields.<br>
<br>
I feel there is no need to cramp stuff up when there
is no real requirement. Simple.php needs to be all
on single lines and that is fine, but for normal
clocking I can't see a reason why it needs to be so
slimline. If you take google calendars for example
(see attached), everything is nicely spread out.<br>
<br>
Maybe the message box restriction was in an old
version of tsheetx v1.2/v1.3<br>
I suppose you could set a limit but if we do then it
should be at least 1000chars, but then if there is
no db limit then why bother?<br>
<br>
<br>
<br>
Regards
<div><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>
<br>
</div>
<div>
<div> On 12/04/2011 18:42, Scott Miller wrote:
<blockquote type="cite">That was just an
example, the sizes were very rough and
adjustable. Considering we now get 7 days of
information on one line of the simple form, I
don't think we're so tight on space that we
need to move to 3-5 lines for each item on the
daily page. I'd like to limit it to no more
than two, the simple form does currently have
this as an option (long description).<br>
<br>
I can see adding a date field is needed, and
with the new form I would like to remove the
clocking box altogether for this form. I am
in agreement that the message box should be
restricted, but I don't believe there is a
limit of 255 characters in either the code or
the database, so I'm curious as to why longer
messages are currently truncated?<br>
<br>
As for editing, I'm proposing you can edit
multiple items at a time with the form, so
there would be no need for an "edit" link, but
yes the 'x' would be to delete the item. With
a test user/test install, maybe play with the
simple form a bit to get a better idea of how
the new daily form might work?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011
at 5:18 PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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">
There are lots of inherent problems with
using the simple timesheet in
conjunction with other forms of time
entry that I have always just disabled
the simple view.<br>
<br>
I think for the daily view, more than
one clock on/off isn't really required.
The more elongated layout could cause
issues as there won't be much room for
the drop down menus if there is long
strings, and the description being so
small i don't think would work.<br>
<br>
A hybrid could work however? - Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client:<br>
</td>
<td valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="3"
valign="top">Message:<br>
</td>
<td colspan="2" rowspan="3"
valign="top">[Message Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td valign="top">[12-4-2011 ]
[8.00 AM]<br>
</td>
<td valign="top">Clock off:<br>
</td>
<td rowspan="1" colspan="2"
valign="top">[12-4-2011 ]
[5.00 PM]</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">[Clock on and/or
off]<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
Then rather than have the clocking box
always visible at the top we could use a
bit of javascript to make it appear -
slide in from behind the menu for
instance?<br>
One of the most annoying things i found
was it took much longer to enter times
than spanned a day boundary. If the
dates are already in this form but
preset to today's date, that would give
users the opportunity to clock over day
boundaries. The other thing that I
found is that there should be validation
on the message box to restrict it to 255
chars or change the db so this limit is
removed as I sometimes entered rather
long messages only to find that it was
truncated at a later date.<br>
<br>
If you wanted to add lots of times could
you do it as follows:<br>
Use my form as the entry method then
have a button that you could click to
add another clocking. The form above is
then cleared and the data you previously
entered is summarised as per Scott's
image above it. the cross could be used
to delete the time and another icon next
to the cross could be added to edit the
stored info. You would then need a
final save btn:<br>
<br>
Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client1<br>
</td>
<td valign="top">Project1<br>
</td>
<td valign="top">Task 1<br>
</td>
<td valign="top">Description<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top">Client 2<br>
</td>
<td valign="top">Project2<br>
</td>
<td valign="top">Task 2<br>
</td>
<td valign="top">Description 2<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td colspan="2" rowspan="1"
valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Client:<br>
</td>
<td colspan="2" rowspan="1"
valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="4"
valign="top">Message:<br>
<br>
</td>
<td colspan="2" rowspan="4"
valign="top">[Message Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td colspan="2" rowspan="1"
valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td colspan="2" rowspan="1"
valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td colspan="2" rowspan="1"
valign="top">[12-4-2011 ]
[8.00 AM]<br>
</td>
</tr>
<tr>
<td valign="top">Clock off: </td>
<td colspan="2" rowspan="1"
valign="top">[12-4-2011 ]
[5.00 PM] </td>
<td valign="top"><br>
</td>
<td valign="top">Add another clock
<br>
</td>
<td valign="top">Submit All!<br>
</td>
</tr>
</tbody>
</table>
<div> <br>
<br>
Cheers<br>
<br>
Mark<br>
<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>
<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ibm-webcastpromo">http://p.sf.net/sfu/ibm-webcastpromo</a></pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a moz-do-not-send="true" 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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/vmware-sfdev2dev">http://p.sf.net/sfu/vmware-sfdev2dev</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: Isabelle V. <ver...@fr...> - 2011-04-14 10:13:33
|
For days and months with accented letters, the solution is probably using something similar to functions in the file: Joomla/libraries/joomla/utilities/date.php: _monthToString and _dayToString functions uses the JText::_ function to correctly display these data. Months and days are already defined in language files. Isabelle. |
|
From: Mark W. <ma...@rw...> - 2011-04-14 10:12:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Scott, <br>
<br>
I thought from your original description that the work you were
doing was a replacement of just the clock on/off box. It makes more
sense now! <br>
<br>
One problem I can foresee is that whenever you submit a new clock,
it will also submit all other clocks on this page, and we may run
into the post size limit. This could easily be avoided by only
submitting individual clock times. Can we implement your idea in
such a way that clock times that already have been entered do not
appear in form fields? An edit button could be added and a bit of
javascript used to enable editting of that particular clock time.
This style of implementation would then lend itself to the scenario
when times have already been 'submitted to a supervisor' and aren't
available for editting.<br>
<br>
Do you intend to add a date field into this form, particularly in
the end time so that clocking over a day boundary can be supported?
The javascript date picker can be configured to add time entry on
the bottom aswell just so you know.<br>
<br>
The clock on/off buttons could be in the same column to save space
in width (one above the other)?<br>
I realise this is just a preliminary version, but i find it is very
easy to click on the wrong drop down menu, I think that some more
space between each one is required.<br>
Also rather than creating a new row when the task field has been
selected, maybe there could be a add a new clock button instead?<br>
<br>
<br>
Cheers<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 14/04/2011 04:42, Peter Lazarus wrote:
<blockquote cite="mid:4DA...@gm..." type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Well I like it. It covers all that is in the daily sheet and
removes the clockon/off thing above. That results in a neater
looking entry form. The clock on now clock off now columns will
become the green/red buttons I assume.<br>
Peter <br>
<br>
On 04/14/2011 08:14 AM, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">I've just submitted my updates, and I've added a
very rough page called newdaily. The submission script doesn't
exist, the grand total doesn't calculate the right thing, but
the rough concept is there, take a look and see what you think.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Wed, Apr 13, 2011 at 9:08 PM, 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;"> Hey Everyone,<br>
<br>
Please could you do a SVN Update, I have gone through and
corrected all<br>
of the db table references in every file.<br>
<br>
Cheers Mark<br>
<br>
--<br>
_____________________________________________<br>
<br>
Mob: <a moz-do-not-send="true" href="tel:07725%20695178"
value="+17725695178">07725 695178</a><br>
Email: <a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Benefiting from Server Virtualization: Beyond Initial
Workload<br>
Consolidation -- Increasing the use of server virtualization
is a top<br>
priority.Virtualization can reduce costs, simplify
management, and improve<br>
application availability and disaster protection. Learn more
about boosting<br>
the value of server virtualization. <a
moz-do-not-send="true"
href="http://p.sf.net/sfu/vmware-sfdev2dev"
target="_blank">http://p.sf.net/sfu/vmware-sfdev2dev</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>
</blockquote>
</div>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/vmware-sfdev2dev">http://p.sf.net/sfu/vmware-sfdev2dev</a></pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a moz-do-not-send="true" 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>
</blockquote>
</body>
</html>
|
|
From: Isabelle V. <ver...@fr...> - 2011-04-14 06:58:40
|
Hello Esteban, With French files, the accented letters are correctly displayed on the browser. The problem is probably how is encoded your "es-ES".ini file: it should be saved as "UTF-8 - No BOM". You can control this using "Notepad++", a free source code editor : http://notepad-plus-plus.org/. About management of dates not linked to the language files: To have dates in your language, you must modify "setlocale" in the file : include/tsx/timezone.inc For my tests, I have this: setlocale(LC_ALL,'fr_FR','fra'); But, I recently noticed a problem for French months with accented letters whereas the meta tag for charset is utf-8. It's amazing! One way to solve this problem is to apply "utf8_encode" to dates. Isabelle. |
|
From: Esteban M. <est...@gm...> - 2011-04-14 05:12:08
|
Hello I have started the spanish Costa Rican translation of time sheet, I have problems with ñ á ó í é ú (tildes) and other beautifull things of my languaje... I hope Upload soon to the svn my work, but if I can't, can sent via mail? -- http://www.nuevaeralatam.com Linux user number 478378 Linux machine number 386687 Tec. Esteban Monge Marín Tel: (506) 8379-3562 “No habrá manera de desarrollarnos y salir de la pobreza mientras los pocos negocios grandes de nuestro medio se entreguen a las economías foráneas y nosotros nos quedemos con solo negocios de pobre, mientras en vez de ser propietarios de nuestro propio país nos convirtamos en un ejército de empleados del exterior” José Figueres Ferrer, 1952. |
|
From: Scott M. <sco...@gm...> - 2011-04-13 22:14:17
|
I've just submitted my updates, and I've added a very rough page called newdaily. The submission script doesn't exist, the grand total doesn't calculate the right thing, but the rough concept is there, take a look and see what you think. -Scott On Wed, Apr 13, 2011 at 9:08 PM, Mark Wrightson <ma...@rw...>wrote: > Hey Everyone, > > Please could you do a SVN Update, I have gone through and corrected all > of the db table references in every file. > > Cheers Mark > > -- > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > |
|
From: Mark W. <ma...@rw...> - 2011-04-13 21:08:13
|
Hey Everyone, Please could you do a SVN Update, I have gone through and corrected all of the db table references in every file. Cheers Mark -- _____________________________________________ Mob: 07725 695178 Email: ma...@rw... |
|
From: Scott M. <sco...@gm...> - 2011-04-13 16:02:58
|
Hey Mark,
I have a 22" at 1680x1050, and I have a single browser window taking up
about 4/5ths of that, so, yeah, I like having lots of width. I would argue
that having any space at all for the description makes it usable, but I
understand not everyone likes stuffing everything in one line, that's why
the big description field was created (I didn't create that by the way, but
I did keep it around :-)
Can you check your changes to the simple form in? I'm using that to create
a rough example of what my vision for a new daily form. And please don't
panic yet, I'm trying to make the daily form better, and together I think we
can do that such that both of us, and therefore our myriad users, are happy.
-Scott
On Wed, Apr 13, 2011 at 3:42 PM, Mark Wrightson <ma...@rw...>wrote:
> Hi Scott,
>
> I think it is a bit much effort to make a mobile version of the site. The
> stretching things width wise isn't just a problem for mobiles. Just
> consider ipads, it could an issue there. Also take my example, I use a 24"
> widescreen monitor (1920x1080) so often have two browsers open each taking
> up half of the screen. Therefore each webpage has 960pixels width. If you
> look at the simple timesheet with that width, it is near enough un-useable.
> I can get a total of 14 characters in the description box before it has to
> overflow.
>
> Why do we need to make things so thin and wide? The current clocking box
> is already in quite a good format in my opinion.
> Yes it needs an update so that dates can be entered and times are done in
> text fields rather drop down menus, but the layout is not cramped and it is
> clean.
>
> The simple timesheet could be improved quite a bit by simply putting the
> description field below the drop down menu fields.
> There is plenty of space in the second row. I have just spent some time
> looking at simple.php and i have gone through and done all the xhtml error
> corrections. (from 125 errors to 6) The 6 errors relate to the drop down
> select boxes that are populated by javascript. I have also tweaked the
> layout type "big work description field". Please go into your config table
> and change simpleTimsheetLayout field to "big work description field". I
> feel this style of layout is better than the single line version as it shows
> much more information whilst using only slightly more vertical room. it
> also means that it is useable on a 960pixel width screen.
>
> I think if you really want to add a new way of clocking in like simple.php
> but for proper clock on/off then it should be a separate page to the
> clocking on/off for daily. Being able to make several clockings at once in
> detail may have its purpose but shouldn't be confused with single clockings
> on a day to day basis.
>
> Can we keep the daily clocking roughly how it is but maybe add a completely
> separate page for multiple clocks?
>
>
> Regards
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 13/04/2011 14:45, Scott Miller wrote:
>
> Ah, I was not thinking about "mobile devices", so I saw no point in
> stretching things vertically.
>
> We could perhaps make two layouts, one for normal screens and another for
> mobile devices, is there an easy way to tell if a mobile device is viewing
> the page?
>
> The current version uses a 'text' field in the database which can hold up
> to 65535 characters, ie. 64kb. I'm fairly certain (but haven't verified)
> there is nothing in the code that cares how long a text message is, but it
> could be affected by the php max_post_size limitation.
>
> -Scott
>
> On Tue, Apr 12, 2011 at 10:26 PM, Mark Wrightson <ma...@rw...
> > wrote:
>
>> The way the current clocking form is, it is suitable for use on small
>> screens i.e. a smart phone which is a good feature.
>> The simple.php doesn't work well on a small screen due to width. Extended
>> descriptions with carriage returns aren't possible either in simple.php
>> whereas the other clocking methods allowed for carriage returns due to the
>> use of textareas instead of single row fields.
>>
>> I feel there is no need to cramp stuff up when there is no real
>> requirement. Simple.php needs to be all on single lines and that is fine,
>> but for normal clocking I can't see a reason why it needs to be so
>> slimline. If you take google calendars for example (see attached),
>> everything is nicely spread out.
>>
>> Maybe the message box restriction was in an old version of tsheetx
>> v1.2/v1.3
>> I suppose you could set a limit but if we do then it should be at least
>> 1000chars, but then if there is no db limit then why bother?
>>
>>
>>
>> Regards
>>
>> Mark
>>
>> _____________________________________________
>>
>> Mob: 07725 695178
>> Email: ma...@rw...
>>
>>
>> On 12/04/2011 18:42, Scott Miller wrote:
>>
>> That was just an example, the sizes were very rough and adjustable.
>> Considering we now get 7 days of information on one line of the simple form,
>> I don't think we're so tight on space that we need to move to 3-5 lines for
>> each item on the daily page. I'd like to limit it to no more than two, the
>> simple form does currently have this as an option (long description).
>>
>> I can see adding a date field is needed, and with the new form I would
>> like to remove the clocking box altogether for this form. I am in agreement
>> that the message box should be restricted, but I don't believe there is a
>> limit of 255 characters in either the code or the database, so I'm curious
>> as to why longer messages are currently truncated?
>>
>> As for editing, I'm proposing you can edit multiple items at a time with
>> the form, so there would be no need for an "edit" link, but yes the 'x'
>> would be to delete the item. With a test user/test install, maybe play with
>> the simple form a bit to get a better idea of how the new daily form might
>> work?
>>
>> -Scott
>>
>> On Tue, Apr 12, 2011 at 5:18 PM, Mark Wrightson <ma...@rw...
>> > wrote:
>>
>>> There are lots of inherent problems with using the simple timesheet in
>>> conjunction with other forms of time entry that I have always just disabled
>>> the simple view.
>>>
>>> I think for the daily view, more than one clock on/off isn't really
>>> required. The more elongated layout could cause issues as there won't be
>>> much room for the drop down menus if there is long strings, and the
>>> description being so small i don't think would work.
>>>
>>> A hybrid could work however? - Maybe:
>>>
>>> Client:
>>> [drop down]
>>> Message:
>>> [Message Box]
>>> Project: [drop down]
>>> Task: [drop down]
>>> Clock On:
>>> [12-4-2011 ] [8.00 AM]
>>> Clock off:
>>> [12-4-2011 ] [5.00 PM]
>>> [Clock on and/or off]
>>>
>>>
>>>
>>>
>>>
>>> Then rather than have the clocking box always visible at the top we could
>>> use a bit of javascript to make it appear - slide in from behind the menu
>>> for instance?
>>> One of the most annoying things i found was it took much longer to enter
>>> times than spanned a day boundary. If the dates are already in this form
>>> but preset to today's date, that would give users the opportunity to clock
>>> over day boundaries. The other thing that I found is that there should be
>>> validation on the message box to restrict it to 255 chars or change the db
>>> so this limit is removed as I sometimes entered rather long messages only to
>>> find that it was truncated at a later date.
>>>
>>> If you wanted to add lots of times could you do it as follows:
>>> Use my form as the entry method then have a button that you could click
>>> to add another clocking. The form above is then cleared and the data you
>>> previously entered is summarised as per Scott's image above it. the cross
>>> could be used to delete the time and another icon next to the cross could be
>>> added to edit the stored info. You would then need a final save btn:
>>>
>>> Maybe:
>>>
>>> Client1
>>> Project1
>>> Task 1
>>> Description
>>> Times
>>> edit/delete
>>> Client 2
>>> Project2
>>> Task 2
>>> Description 2
>>> Times
>>> edit/delete
>>>
>>>
>>>
>>>
>>>
>>> Client:
>>> [drop down]
>>> Message:
>>>
>>> [Message Box]
>>> Project: [drop down]
>>> Task: [drop down]
>>> Clock On:
>>> [12-4-2011 ] [8.00 AM]
>>> Clock off: [12-4-2011 ] [5.00 PM]
>>> Add another clock
>>> Submit All!
>>>
>>>
>>> Cheers
>>>
>>> Mark
>>>
>>> _____________________________________________
>>>
>>> Mob: 07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 12/04/2011 17:11, Scott Miller wrote:
>>>
>>> Ok, so, I'm thinking about redesigning the daily time entry form(s).
>>> Several months ago someone (may have been you, Mark) asked about changing
>>> the simple form to have people record starting and ending times, and I
>>> vehemently disagree with doing that, but, remembering that got me thinking
>>> that perhaps the daily form should look more like the simple form.
>>>
>>> The vision I currently have is something like the attached image, where
>>> you have the client/project/task description, then some radio buttons to
>>> clock on and off now, as well as time start/stop entry areas. We could then
>>> remove the whole "pop up" dialog thing currently at the top of the page.
>>>
>>> How does this sound? can we improve this form even more?
>>>
>>> -Scott
>>>
>>> On Tue, Apr 12, 2011 at 2:48 PM, Scott Miller <sco...@gm...>wrote:
>>>
>>>> Hey Mark,
>>>>
>>>> I'm going to add my answers to the middle of your text below:
>>>>
>>>> On Mon, Apr 11, 2011 at 10:50 PM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>> Ah ok fair enough. Just wondering - do you think it would be a good
>>>>> idea to get all the forms working again and get to a point where we know the
>>>>> core functionality works again before we do much more redesigning??
>>>>>
>>>>
>>>> I think it depends on the situation. If we want to redesign
>>>> something, now's the time to do it, so why waste time fixing some area that
>>>> you're planning to completely redo? If you're not planning to redo an area,
>>>> then, yes, getting those forms to work again would be working toward the end
>>>> goal :-)
>>>>
>>>>>
>>>>> I'm not going to be able to do very much atall over the next couple of
>>>>> months as it is "all hands on deck" to get my disertation done. On another
>>>>> note I have pretty much completed a upgrade system. It does the following
>>>>> interactively:
>>>>>
>>>>> 1. backup of db
>>>>> 2.checks for any prerequisites
>>>>> 3. performs db updates
>>>>> 4. complete
>>>>>
>>>>> The only problem I currently have is that it works fantastically when
>>>>> moving from version v1.5.3 to v1.5.4 or even v1.5.3 to v1.6.0 as long as it
>>>>> is a single jump. I can't currently handle: v1.5.3 to v1.5.4 to v1.6.0.
>>>>>
>>>>> an upgrade basically consists of a new class file called for example:
>>>>> upgradev1_5_3_to_v1_5_4.class.php
>>>>> so another file could be created i.e.
>>>>> upgradev1_5_3_to_v1_6_0.class.php in which case only a single upgrade
>>>>> step
>>>>> is required and that will work fine (but starts to get labour intensive
>>>>> creating files for every permutation).
>>>>>
>>>>> I've written a script that can work out the necessary upgrade path i.e.
>>>>>
>>>>> going from v1.5.3 to v1.6.0
>>>>> run the following upgrades:
>>>>> upgradev1_5_3_to_v1_5_4.class.php
>>>>> upgradev1_5_4_to_v1_6_0.class.php
>>>>>
>>>>> But this is the point where I stopped as I was slightly concerned that
>>>>> if the database version is 1.5.3 and the code version is 1.6.0 and the code
>>>>> base had changed significantly in 1.6.0 there is then a possibility some of
>>>>> the code in the class file "upgradev1_5_3_to_v1_5_4.class.php" would no
>>>>> longer work correctly.
>>>>>
>>>>> Have you got any thoughts on this problem?
>>>>>
>>>>
>>>> Running each step is the way to go. Modifying the database, since we
>>>> shouldn't be looking to the databases for much more than the version number
>>>> during the upgrade, it shouldn't ever matter what information is in the
>>>> database while moving from one version through however many upgrade files as
>>>> needed to get to what the current database schema should look like. As long
>>>> as each step is valid, you should be able to go through all the steps. This
>>>> is how the upgrade process has worked in the past.
>>>>
>>>> Although it is tempting to write upgrade scripts that are able to jump
>>>> from a past version directly to the new version, this is not recommended
>>>> because, as you've discovered it makes loads more work for future upgrades.
>>>>
>>>> The upgrade should not attempt to figure out what code files need to be
>>>> changed/added/deleted. The upgrade process should look like this:
>>>>
>>>> 1. Old installation with old database
>>>> 2. download new version
>>>> 3. unpack the new version
>>>> 4. rename the old version's directory something different: tsx ->
>>>> tsx.old or use version numbers or whatever
>>>> 5. move the new unpacked version to the original directory's name
>>>> 6. optionally copy a configuration file or two from the old system to
>>>> the new system to assist with the upgrade
>>>> 6. open a web browser to the site
>>>>
>>>> In this way, the new version should be a completely clean upgrade, so
>>>> the only work that needs to be accomplished is the upgrading of the
>>>> database.
>>>>
>>>> Cheers
>>>>>
>>>>> Mark
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob: 07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>> On 11/04/2011 23:33, Scott Miller wrote:
>>>>>
>>>>> I had managed to wrap my brain around most of it last Friday, but I
>>>>> didn't get a chance to mess with it today.
>>>>>
>>>>> I'm actually toying with totally redesigning the daily form, I'll try
>>>>> to email you tomorrow detailing some ideas I had to redesign it, and we can
>>>>> bat it back and forth.
>>>>>
>>>>> -Scott
>>>>>
>>>>> On Mon, Apr 11, 2011 at 10:30 PM, Mark Wrightson <
>>>>> ma...@rw...> wrote:
>>>>>
>>>>>> Hi Scott,
>>>>>>
>>>>>> The "quite broken" aspect is probably to do with the OO updates. Can
>>>>>> i help atall??
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> _____________________________________________
>>>>>>
>>>>>> Mob: 07725 695178
>>>>>> Email: ma...@rw...
>>>>>>
>>>>>>
>>>>>> On 11/04/2011 21:05, Scott Miller wrote:
>>>>>>
>>>>>> Hey Isabelle, I am also attempting to work on the clockOnOff stuff, as
>>>>>> it appears to be quite broken...
>>>>>>
>>>>>> Yes the "change the date" stuff is in Javascript, but that doesn't
>>>>>> mean we can't embed PHP within the java stuff, but I would also like to
>>>>>> enhance, or even replace that whole area of the new system, so,
>>>>>> internationalizing that would probably be premature at this point.
>>>>>>
>>>>>> The submit times and supervisors stuff are the "not ready for prime
>>>>>> time" attempts at a submission & approval system for the timesheet system.
>>>>>> Again, internationalization of this area is probably premature...
>>>>>>
>>>>>> I would love to see the excel system name changes you've made, go
>>>>>> ahead and submit that.
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>> On Mon, Apr 11, 2011 at 7:43 PM, Isabelle Vergely <
>>>>>> ver...@fr...> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> My today commit on Directory branches/txsheet-2.0-demo/(=> Revision
>>>>>>> 293)
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>> - Modifications for internationalization:
>>>>>>> * en-GB.ini, fr-FR.ini
>>>>>>> * clockOnOff.inc, clockOnOff_core_new.inc, clock_popup.php,
>>>>>>> stopwatch.php
>>>>>>> * template.php, common.class.php, footer.inc
>>>>>>> * absences.php, monthly.php, simple.php, weekly.php
>>>>>>> - Small modification in timesheet.css
>>>>>>>
>>>>>>> Questions on txsheet-2.0-demo:
>>>>>>> ------------------------------
>>>>>>> - I have also made changes for excel filenames more representative
>>>>>>> than
>>>>>>> "Timesheet_" . date("Y-m").".xls"; I can also commit these changes.
>>>>>>> - I would like to "translate calendar" when displayed for "Change the
>>>>>>> date"
>>>>>>> but it seems to be in js file; it is right?
>>>>>>> - What are the goals of the pages "submit times" and "supervisors"?
>>>>>>>
>>>>>>> Isabelle.
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Forrester Wave Report - Recovery time is now measured in hours and
>>>>>>> minutes
>>>>>>> not days. Key insights are discussed in the 2010 Forrester Wave
>>>>>>> Report as
>>>>>>> part of an in-depth evaluation of disaster recovery service
>>>>>>> providers.
>>>>>>> Forrester found the best-in-class provider in terms of services and
>>>>>>> vision.
>>>>>>> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
>>>>>>> _______________________________________________
>>>>>>> Tsheetx-developers mailing list
>>>>>>> Tsh...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Forrester Wave Report - Recovery time is now measured in hours and minutes
>>>>>> not days. Key insights are discussed in the 2010 Forrester Wave Report as
>>>>>> part of an in-depth evaluation of disaster recovery service providers.
>>>>>> Forrester found the best-in-class provider in terms of services and vision.
>>>>>> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Tsheetx-developers mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Mark W. <ma...@rw...> - 2011-04-13 15:55:03
|
<!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">
I have also added to the daily clock on/off box a show/hide option.
It is only a simple link at the moment. Please can I have some
feedback on the idea? I think it reduces the clutter on the daily
page when you don't want to clock on or off.<br>
<br>
Cheers<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 13/04/2011 16:42, Mark Wrightson wrote:
<blockquote cite="mid:4DA...@rw..."
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
Hi Scott, <br>
<br>
I think it is a bit much effort to make a mobile version of the
site. The stretching things width wise isn't just a problem for
mobiles. Just consider ipads, it could an issue there. Also take
my example, I use a 24" widescreen monitor (1920x1080) so often
have two browsers open each taking up half of the screen.
Therefore each webpage has 960pixels width. If you look at the
simple timesheet with that width, it is near enough un-useable. I
can get a total of 14 characters in the description box before it
has to overflow.<br>
<br>
Why do we need to make things so thin and wide? The current
clocking box is already in quite a good format in my opinion.<br>
Yes it needs an update so that dates can be entered and times are
done in text fields rather drop down menus, but the layout is not
cramped and it is clean.<br>
<br>
The simple timesheet could be improved quite a bit by simply
putting the description field below the drop down menu fields.<br>
There is plenty of space in the second row. I have just spent
some time looking at simple.php and i have gone through and done
all the xhtml error corrections. (from 125 errors to 6) The 6
errors relate to the drop down select boxes that are populated by
javascript. I have also tweaked the layout type "big work
description field". Please go into your config table and change
simpleTimsheetLayout field to "big work description field". I
feel this style of layout is better than the single line version
as it shows much more information whilst using only slightly more
vertical room. it also means that it is useable on a 960pixel
width screen.<br>
<br>
I think if you really want to add a new way of clocking in like
simple.php but for proper clock on/off then it should be a
separate page to the clocking on/off for daily. Being able to
make several clockings at once in detail may have its purpose but
shouldn't be confused with single clockings on a day to day basis.<br>
<br>
Can we keep the daily clocking roughly how it is but maybe add a
completely separate page for multiple clocks?<br>
<br>
Regards<br>
Mark<br>
<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 13/04/2011 14:45, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">Ah, I was not thinking about "mobile devices", so I
saw no point in stretching things vertically.<br>
<br>
We could perhaps make two layouts, one for normal screens and
another for mobile devices, is there an easy way to tell if a
mobile device is viewing the page?<br>
<br>
The current version uses a 'text' field in the database which
can hold up to 65535 characters, ie. 64kb. I'm fairly certain
(but haven't verified) there is nothing in the code that cares
how long a text message is, but it could be affected by the php
max_post_size limitation.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 10:26 PM, 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"> The way the current
clocking form is, it is suitable for use on small screens
i.e. a smart phone which is a good feature.<br>
The simple.php doesn't work well on a small screen due to
width. Extended descriptions with carriage returns aren't
possible either in simple.php whereas the other clocking
methods allowed for carriage returns due to the use of
textareas instead of single row fields.<br>
<br>
I feel there is no need to cramp stuff up when there is no
real requirement. Simple.php needs to be all on single
lines and that is fine, but for normal clocking I can't
see a reason why it needs to be so slimline. If you take
google calendars for example (see attached), everything is
nicely spread out.<br>
<br>
Maybe the message box restriction was in an old version of
tsheetx v1.2/v1.3<br>
I suppose you could set a limit but if we do then it
should be at least 1000chars, but then if there is no db
limit then why bother?<br>
<br>
<br>
<br>
Regards
<div class="im"><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>
<br>
</div>
<div>
<div class="h5"> On 12/04/2011 18:42, Scott Miller
wrote:
<blockquote type="cite">That was just an example, the
sizes were very rough and adjustable. Considering we
now get 7 days of information on one line of the
simple form, I don't think we're so tight on space
that we need to move to 3-5 lines for each item on
the daily page. I'd like to limit it to no more
than two, the simple form does currently have this
as an option (long description).<br>
<br>
I can see adding a date field is needed, and with
the new form I would like to remove the clocking box
altogether for this form. I am in agreement that
the message box should be restricted, but I don't
believe there is a limit of 255 characters in either
the code or the database, so I'm curious as to why
longer messages are currently truncated?<br>
<br>
As for editing, I'm proposing you can edit multiple
items at a time with the form, so there would be no
need for an "edit" link, but yes the 'x' would be to
delete the item. With a test user/test install,
maybe play with the simple form a bit to get a
better idea of how the new daily form might work?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at
5:18 PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> There are
lots of inherent problems with using the
simple timesheet in conjunction with other
forms of time entry that I have always just
disabled the simple view.<br>
<br>
I think for the daily view, more than one
clock on/off isn't really required. The more
elongated layout could cause issues as there
won't be much room for the drop down menus if
there is long strings, and the description
being so small i don't think would work.<br>
<br>
A hybrid could work however? - Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client:<br>
</td>
<td valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="3" valign="top">Message:<br>
</td>
<td colspan="2" rowspan="3" valign="top">[Message
Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td valign="top">[12-4-2011 ] [8.00
AM]<br>
</td>
<td valign="top">Clock off:<br>
</td>
<td rowspan="1" colspan="2" valign="top">[12-4-2011
] [5.00 PM]</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">[Clock on and/or off]<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
Then rather than have the clocking box always
visible at the top we could use a bit of
javascript to make it appear - slide in from
behind the menu for instance?<br>
One of the most annoying things i found was it
took much longer to enter times than spanned a
day boundary. If the dates are already in
this form but preset to today's date, that
would give users the opportunity to clock over
day boundaries. The other thing that I found
is that there should be validation on the
message box to restrict it to 255 chars or
change the db so this limit is removed as I
sometimes entered rather long messages only to
find that it was truncated at a later date.<br>
<br>
If you wanted to add lots of times could you
do it as follows:<br>
Use my form as the entry method then have a
button that you could click to add another
clocking. The form above is then cleared and
the data you previously entered is summarised
as per Scott's image above it. the cross
could be used to delete the time and another
icon next to the cross could be added to edit
the stored info. You would then need a final
save btn:<br>
<br>
Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client1<br>
</td>
<td valign="top">Project1<br>
</td>
<td valign="top">Task 1<br>
</td>
<td valign="top">Description<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top">Client 2<br>
</td>
<td valign="top">Project2<br>
</td>
<td valign="top">Task 2<br>
</td>
<td valign="top">Description 2<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td colspan="2" rowspan="1" valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Client:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
<td colspan="1" rowspan="4" valign="top">Message:<br>
<br>
</td>
<td colspan="2" rowspan="4" valign="top">[Message
Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [8.00 AM]<br>
</td>
</tr>
<tr>
<td valign="top">Clock off: </td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [5.00 PM] </td>
<td valign="top"><br>
</td>
<td valign="top">Add another clock <br>
</td>
<td valign="top">Submit All!<br>
</td>
</tr>
</tbody>
</table>
<div> <br>
<br>
Cheers<br>
<br>
Mark<br>
<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>
<br>
</div>
<div>
<div> On 12/04/2011 17:11, Scott Miller
wrote:
<blockquote type="cite">Ok, so, I'm
thinking about redesigning the daily
time entry form(s). Several months ago
someone (may have been you, Mark) asked
about changing the simple form to have
people record starting and ending times,
and I vehemently disagree with doing
that, but, remembering that got me
thinking that perhaps the daily form
should look more like the simple form.<br>
<br>
The vision I currently have is something
like the attached image, where you have
the client/project/task description,
then some radio buttons to clock on and
off now, as well as time start/stop
entry areas. We could then remove the
whole "pop up" dialog thing currently at
the top of the page.<br>
<br>
How does this sound? can we improve
this form even more?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12,
2011 at 2:48 PM, 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;">Hey Mark,<br>
<br>
I'm going to add my answers to the
middle of your text below:<br>
<br>
<div class="gmail_quote">
<div>On Mon, Apr 11, 2011 at 10:50
PM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> Ah ok fair
enough. Just wondering - do
you think it would be a good
idea to get all the forms
working again and get to a
point where we know the core
functionality works again
before we do much more
redesigning??<br>
</div>
</blockquote>
</div>
<div><font color="#339999"><br>
</font>
<div style="margin-left: 40px;
color: rgb(0, 0, 153);">I
think it depends on the
situation. If we want to
redesign something, now's the
time to do it, so why waste
time fixing some area that
you're planning to completely
redo? If you're not planning
to redo an area, then, yes,
getting those forms to work
again would be working toward
the end goal :-)<br>
</div>
</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 bgcolor="#ffffff"
text="#000000"> <br>
I'm not going to be able to
do very much atall over the
next couple of months as it
is "all hands on deck" to
get my disertation done. On
another note I have pretty
much completed a upgrade
system. It does the
following interactively:<br>
<br>
1. backup of db<br>
2.checks for any
prerequisites<br>
3. performs db updates<br>
4. complete<br>
<br>
The only problem I currently
have is that it works
fantastically when moving
from version v1.5.3 to
v1.5.4 or even v1.5.3 to
v1.6.0 as long as it is a
single jump. I can't
currently handle: v1.5.3 to
v1.5.4 to v1.6.0.<br>
<br>
an upgrade basically
consists of a new class file
called for example:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
so another file could be
created i.e.<br>
upgradev1_5_3_to_v1_6_0.class.php
in which case only a single
upgrade step<br>
is required and that will
work fine (but starts to get
labour intensive creating
files for every
permutation).<br>
<br>
I've written a script that
can work out the necessary
upgrade path i.e. <br>
going from v1.5.3 to v1.6.0<br>
run the following upgrades:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
upgradev1_5_4_to_v1_6_0.class.php<br>
<br>
But this is the point where
I stopped as I was slightly
concerned that if the
database version is 1.5.3
and the code version is
1.6.0 and the code base had
changed significantly in
1.6.0 there is then a
possibility some of the code
in the class file
"upgradev1_5_3_to_v1_5_4.class.php"
would no longer work
correctly. <br>
<br>
Have you got any thoughts on
this problem? <br>
</div>
</blockquote>
</div>
<div><br>
<div style="margin-left: 40px;
color: rgb(51, 102, 102);"><span
style="color: rgb(0, 0,
153);"> Running each step is
the way to go. Modifying
the database, since we
shouldn't be looking to the
databases for much more than
the version number during
the upgrade, it shouldn't
ever matter what information
is in the database while
moving from one version
through however many upgrade
files as needed to get to
what the current database
schema should look like. As
long as each step is valid,
you should be able to go
through all the steps. This
is how the upgrade process
has worked in the past.</span><br
style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">Although it is
tempting to write upgrade
scripts that are able to
jump from a past version
directly to the new version,
this is not recommended
because, as you've
discovered it makes loads
more work for future
upgrades.</span><br
style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">The upgrade should
not attempt to figure out
what code files need to be
changed/added/deleted. The
upgrade process should look
like this:</span><br
style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">1. Old installation
with old database</span><br
style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">2. download new
version</span><br
style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">3. unpack the new
version</span><br
style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">4. rename the old
version's directory
something different: tsx
-> tsx.old or use
version numbers or whatever</span><br
style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">5. move the new
unpacked version to the
original directory's name</span><br
style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">6. optionally copy a
configuration file or two
from the old system to the
new system to assist with
the upgrade</span><br
style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">6. open a web browser
to the site</span><br
style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">In this way, the new
version should be a
completely clean upgrade, so
the only work that needs to
be accomplished is the
upgrading of the database.</span><br>
</div>
<br>
</div>
<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 bgcolor="#ffffff"
text="#000000"> Cheers
<div><br>
Mark<br>
<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>
<br>
</div>
<div>
<div> On 11/04/2011
23:33, Scott Miller
wrote:
<blockquote
type="cite">I had
managed to wrap my
brain around most of
it last Friday, but
I didn't get a
chance to mess with
it today. <br>
<br>
I'm actually toying
with totally
redesigning the
daily form, I'll try
to email you
tomorrow detailing
some ideas I had to
redesign it, and we
can bat it back and
forth.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11, 2011
at 10:30 PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">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">
Hi Scott, <br>
<br>
The "quite
broken" aspect
is probably to
do with the OO
updates. Can
i help atall??<br>
<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> <br>
On 11/04/2011
21:05, Scott
Miller wrote:
<blockquote
type="cite">Hey
Isabelle, I am
also
attempting to
work on the
clockOnOff
stuff, as it
appears to be
quite
broken...<br>
<br>
Yes the
"change the
date" stuff is
in Javascript,
but that
doesn't mean
we can't embed
PHP within the
java stuff,
but I would
also like to
enhance, or
even replace
that whole
area of the
new system,
so,
internationalizing
that would
probably be
premature at
this point.<br>
<br>
The submit
times and
supervisors
stuff are the
"not ready for
prime time"
attempts at a
submission
& approval
system for the
timesheet
system.
Again,
internationalization
of this area
is probably
premature...<br>
<br>
I would love
to see the
excel system
name changes
you've made,
go ahead and
submit that.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11,
2011 at 7:43
PM, Isabelle
Vergely <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ver...@fr..."
target="_blank">ver...@fr...</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;">Hello,<br>
<br>
My today
commit on
Directory
branches/txsheet-2.0-demo/(=>
Revision 293)<br>
------------------------------------------------------------------------<br>
-
Modifications
for
internationalization:<br>
* en-GB.ini,
fr-FR.ini<br>
*
clockOnOff.inc,
clockOnOff_core_new.inc,
clock_popup.php,
stopwatch.php<br>
*
template.php,
common.class.php,
footer.inc<br>
*
absences.php,
monthly.php,
simple.php,
weekly.php<br>
- Small
modification
in
timesheet.css<br>
<br>
Questions on
txsheet-2.0-demo:<br>
------------------------------<br>
- I have also
made changes
for excel
filenames more
representative
than<br>
"Timesheet_" .
date("Y-m").".xls";
I can also
commit these
changes.<br>
- I would like
to "translate
calendar" when
displayed for
"Change the
date"<br>
but it seems
to be in js
file; it is
right?<br>
- What are the
goals of the
pages "submit
times" and
"supervisors"?<br>
<br>
Isabelle.<br>
<br>
------------------------------------------------------------------------------<br>
Forrester Wave
Report -
Recovery time
is now
measured in
hours and
minutes<br>
not days. Key
insights are
discussed in
the 2010
Forrester Wave
Report as<br>
part of an
in-depth
evaluation of
disaster
recovery
service
providers.<br>
Forrester
found the
best-in-class
provider in
terms of
services and
vision.<br>
Read this
report now! <a
moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo"
target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo" target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ibm-webcastpromo">http://p.sf.net/sfu/ibm-webcastpromo</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: Mark W. <ma...@rw...> - 2011-04-13 15:43:09
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Scott, <br>
<br>
I think it is a bit much effort to make a mobile version of the
site. The stretching things width wise isn't just a problem for
mobiles. Just consider ipads, it could an issue there. Also take
my example, I use a 24" widescreen monitor (1920x1080) so often have
two browsers open each taking up half of the screen. Therefore each
webpage has 960pixels width. If you look at the simple timesheet
with that width, it is near enough un-useable. I can get a total of
14 characters in the description box before it has to overflow.<br>
<br>
Why do we need to make things so thin and wide? The current
clocking box is already in quite a good format in my opinion.<br>
Yes it needs an update so that dates can be entered and times are
done in text fields rather drop down menus, but the layout is not
cramped and it is clean.<br>
<br>
The simple timesheet could be improved quite a bit by simply putting
the description field below the drop down menu fields.<br>
There is plenty of space in the second row. I have just spent some
time looking at simple.php and i have gone through and done all the
xhtml error corrections. (from 125 errors to 6) The 6 errors relate
to the drop down select boxes that are populated by javascript. I
have also tweaked the layout type "big work description field".
Please go into your config table and change simpleTimsheetLayout
field to "big work description field". I feel this style of layout
is better than the single line version as it shows much more
information whilst using only slightly more vertical room. it also
means that it is useable on a 960pixel width screen.<br>
<br>
I think if you really want to add a new way of clocking in like
simple.php but for proper clock on/off then it should be a separate
page to the clocking on/off for daily. Being able to make several
clockings at once in detail may have its purpose but shouldn't be
confused with single clockings on a day to day basis.<br>
<br>
Can we keep the daily clocking roughly how it is but maybe add a
completely separate page for multiple clocks?<br>
<br>
Regards<br>
Mark<br>
<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 13/04/2011 14:45, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">Ah, I was not thinking about "mobile devices", so I
saw no point in stretching things vertically.<br>
<br>
We could perhaps make two layouts, one for normal screens and
another for mobile devices, is there an easy way to tell if a
mobile device is viewing the page?<br>
<br>
The current version uses a 'text' field in the database which can
hold up to 65535 characters, ie. 64kb. I'm fairly certain (but
haven't verified) there is nothing in the code that cares how long
a text message is, but it could be affected by the php
max_post_size limitation.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 10:26 PM, 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"> The way the current
clocking form is, it is suitable for use on small screens
i.e. a smart phone which is a good feature.<br>
The simple.php doesn't work well on a small screen due to
width. Extended descriptions with carriage returns aren't
possible either in simple.php whereas the other clocking
methods allowed for carriage returns due to the use of
textareas instead of single row fields.<br>
<br>
I feel there is no need to cramp stuff up when there is no
real requirement. Simple.php needs to be all on single
lines and that is fine, but for normal clocking I can't see
a reason why it needs to be so slimline. If you take google
calendars for example (see attached), everything is nicely
spread out.<br>
<br>
Maybe the message box restriction was in an old version of
tsheetx v1.2/v1.3<br>
I suppose you could set a limit but if we do then it should
be at least 1000chars, but then if there is no db limit then
why bother?<br>
<br>
<br>
<br>
Regards
<div class="im"><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>
<br>
</div>
<div>
<div class="h5"> On 12/04/2011 18:42, Scott Miller wrote:
<blockquote type="cite">That was just an example, the
sizes were very rough and adjustable. Considering we
now get 7 days of information on one line of the
simple form, I don't think we're so tight on space
that we need to move to 3-5 lines for each item on the
daily page. I'd like to limit it to no more than two,
the simple form does currently have this as an option
(long description).<br>
<br>
I can see adding a date field is needed, and with the
new form I would like to remove the clocking box
altogether for this form. I am in agreement that the
message box should be restricted, but I don't believe
there is a limit of 255 characters in either the code
or the database, so I'm curious as to why longer
messages are currently truncated?<br>
<br>
As for editing, I'm proposing you can edit multiple
items at a time with the form, so there would be no
need for an "edit" link, but yes the 'x' would be to
delete the item. With a test user/test install, maybe
play with the simple form a bit to get a better idea
of how the new daily form might work?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 5:18
PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> There are
lots of inherent problems with using the simple
timesheet in conjunction with other forms of
time entry that I have always just disabled the
simple view.<br>
<br>
I think for the daily view, more than one clock
on/off isn't really required. The more
elongated layout could cause issues as there
won't be much room for the drop down menus if
there is long strings, and the description being
so small i don't think would work.<br>
<br>
A hybrid could work however? - Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client:<br>
</td>
<td valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="3" valign="top">Message:<br>
</td>
<td colspan="2" rowspan="3" valign="top">[Message
Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td valign="top">[12-4-2011 ] [8.00
AM]<br>
</td>
<td valign="top">Clock off:<br>
</td>
<td rowspan="1" colspan="2" valign="top">[12-4-2011
] [5.00 PM]</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">[Clock on and/or off]<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
Then rather than have the clocking box always
visible at the top we could use a bit of
javascript to make it appear - slide in from
behind the menu for instance?<br>
One of the most annoying things i found was it
took much longer to enter times than spanned a
day boundary. If the dates are already in this
form but preset to today's date, that would give
users the opportunity to clock over day
boundaries. The other thing that I found is
that there should be validation on the message
box to restrict it to 255 chars or change the db
so this limit is removed as I sometimes entered
rather long messages only to find that it was
truncated at a later date.<br>
<br>
If you wanted to add lots of times could you do
it as follows:<br>
Use my form as the entry method then have a
button that you could click to add another
clocking. The form above is then cleared and
the data you previously entered is summarised as
per Scott's image above it. the cross could be
used to delete the time and another icon next to
the cross could be added to edit the stored
info. You would then need a final save btn:<br>
<br>
Maybe:<br>
<br>
<table border="1" cellpadding="2"
cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client1<br>
</td>
<td valign="top">Project1<br>
</td>
<td valign="top">Task 1<br>
</td>
<td valign="top">Description<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top">Client 2<br>
</td>
<td valign="top">Project2<br>
</td>
<td valign="top">Task 2<br>
</td>
<td valign="top">Description 2<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td colspan="2" rowspan="1" valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Client:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
<td colspan="1" rowspan="4" valign="top">Message:<br>
<br>
</td>
<td colspan="2" rowspan="4" valign="top">[Message
Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td colspan="2" rowspan="1" valign="top">[drop
down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [8.00 AM]<br>
</td>
</tr>
<tr>
<td valign="top">Clock off: </td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [5.00 PM] </td>
<td valign="top"><br>
</td>
<td valign="top">Add another clock <br>
</td>
<td valign="top">Submit All!<br>
</td>
</tr>
</tbody>
</table>
<div> <br>
<br>
Cheers<br>
<br>
Mark<br>
<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>
<br>
</div>
<div>
<div> On 12/04/2011 17:11, Scott Miller wrote:
<blockquote type="cite">Ok, so, I'm thinking
about redesigning the daily time entry
form(s). Several months ago someone (may
have been you, Mark) asked about changing
the simple form to have people record
starting and ending times, and I
vehemently disagree with doing that, but,
remembering that got me thinking that
perhaps the daily form should look more
like the simple form.<br>
<br>
The vision I currently have is something
like the attached image, where you have
the client/project/task description, then
some radio buttons to clock on and off
now, as well as time start/stop entry
areas. We could then remove the whole
"pop up" dialog thing currently at the top
of the page.<br>
<br>
How does this sound? can we improve this
form even more?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12,
2011 at 2:48 PM, 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;">Hey Mark,<br>
<br>
I'm going to add my answers to the
middle of your text below:<br>
<br>
<div class="gmail_quote">
<div>On Mon, Apr 11, 2011 at 10:50
PM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> Ah ok fair
enough. Just wondering - do
you think it would be a good
idea to get all the forms
working again and get to a
point where we know the core
functionality works again
before we do much more
redesigning??<br>
</div>
</blockquote>
</div>
<div><font color="#339999"><br>
</font>
<div style="margin-left: 40px;
color: rgb(0, 0, 153);">I think
it depends on the situation. If
we want to redesign something,
now's the time to do it, so why
waste time fixing some area that
you're planning to completely
redo? If you're not planning to
redo an area, then, yes, getting
those forms to work again would
be working toward the end goal
:-)<br>
</div>
</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 bgcolor="#ffffff"
text="#000000"> <br>
I'm not going to be able to do
very much atall over the next
couple of months as it is "all
hands on deck" to get my
disertation done. On another
note I have pretty much
completed a upgrade system.
It does the following
interactively:<br>
<br>
1. backup of db<br>
2.checks for any prerequisites<br>
3. performs db updates<br>
4. complete<br>
<br>
The only problem I currently
have is that it works
fantastically when moving from
version v1.5.3 to v1.5.4 or
even v1.5.3 to v1.6.0 as long
as it is a single jump. I
can't currently handle: v1.5.3
to v1.5.4 to v1.6.0.<br>
<br>
an upgrade basically consists
of a new class file called for
example:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
so another file could be
created i.e.<br>
upgradev1_5_3_to_v1_6_0.class.php
in which case only a single
upgrade step<br>
is required and that will work
fine (but starts to get labour
intensive creating files for
every permutation).<br>
<br>
I've written a script that can
work out the necessary upgrade
path i.e. <br>
going from v1.5.3 to v1.6.0<br>
run the following upgrades:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
upgradev1_5_4_to_v1_6_0.class.php<br>
<br>
But this is the point where I
stopped as I was slightly
concerned that if the database
version is 1.5.3 and the code
version is 1.6.0 and the code
base had changed significantly
in 1.6.0 there is then a
possibility some of the code
in the class file
"upgradev1_5_3_to_v1_5_4.class.php"
would no longer work
correctly. <br>
<br>
Have you got any thoughts on
this problem? <br>
</div>
</blockquote>
</div>
<div><br>
<div style="margin-left: 40px;
color: rgb(51, 102, 102);"><span
style="color: rgb(0, 0, 153);"> Running
each step is the way to go.
Modifying the database, since
we shouldn't be looking to the
databases for much more than
the version number during the
upgrade, it shouldn't ever
matter what information is in
the database while moving from
one version through however
many upgrade files as needed
to get to what the current
database schema should look
like. As long as each step is
valid, you should be able to
go through all the steps.
This is how the upgrade
process has worked in the
past.</span><br style="color:
rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">Although it is tempting
to write upgrade scripts that
are able to jump from a past
version directly to the new
version, this is not
recommended because, as you've
discovered it makes loads more
work for future upgrades.</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">The upgrade should not
attempt to figure out what
code files need to be
changed/added/deleted. The
upgrade process should look
like this:</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">1. Old installation
with old database</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">2. download new version</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">3. unpack the new
version</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">4. rename the old
version's directory something
different: tsx -> tsx.old
or use version numbers or
whatever</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">5. move the new
unpacked version to the
original directory's name</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">6. optionally copy a
configuration file or two from
the old system to the new
system to assist with the
upgrade</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0,
153);">6. open a web browser
to the site</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0,
153);">In this way, the new
version should be a completely
clean upgrade, so the only
work that needs to be
accomplished is the upgrading
of the database.</span><br>
</div>
<br>
</div>
<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 bgcolor="#ffffff"
text="#000000"> Cheers
<div><br>
Mark<br>
<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>
<br>
</div>
<div>
<div> On 11/04/2011 23:33,
Scott Miller wrote:
<blockquote type="cite">I
had managed to wrap my
brain around most of
it last Friday, but I
didn't get a chance to
mess with it today. <br>
<br>
I'm actually toying
with totally
redesigning the daily
form, I'll try to
email you tomorrow
detailing some ideas I
had to redesign it,
and we can bat it back
and forth.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11, 2011 at
10:30 PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">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">
Hi Scott, <br>
<br>
The "quite
broken" aspect
is probably to
do with the OO
updates. Can i
help atall??<br>
<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> <br>
On 11/04/2011
21:05, Scott
Miller wrote:
<blockquote
type="cite">Hey
Isabelle, I am
also
attempting to
work on the
clockOnOff
stuff, as it
appears to be
quite
broken...<br>
<br>
Yes the
"change the
date" stuff is
in Javascript,
but that
doesn't mean
we can't embed
PHP within the
java stuff,
but I would
also like to
enhance, or
even replace
that whole
area of the
new system,
so,
internationalizing
that would
probably be
premature at
this point.<br>
<br>
The submit
times and
supervisors
stuff are the
"not ready for
prime time"
attempts at a
submission
& approval
system for the
timesheet
system.
Again,
internationalization
of this area
is probably
premature...<br>
<br>
I would love
to see the
excel system
name changes
you've made,
go ahead and
submit that.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11,
2011 at 7:43
PM, Isabelle
Vergely <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ver...@fr..."
target="_blank">ver...@fr...</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;">Hello,<br>
<br>
My today
commit on
Directory
branches/txsheet-2.0-demo/(=>
Revision 293)<br>
------------------------------------------------------------------------<br>
-
Modifications
for
internationalization:<br>
* en-GB.ini,
fr-FR.ini<br>
*
clockOnOff.inc,
clockOnOff_core_new.inc,
clock_popup.php,
stopwatch.php<br>
*
template.php,
common.class.php,
footer.inc<br>
*
absences.php,
monthly.php,
simple.php,
weekly.php<br>
- Small
modification
in
timesheet.css<br>
<br>
Questions on
txsheet-2.0-demo:<br>
------------------------------<br>
- I have also
made changes
for excel
filenames more
representative
than<br>
"Timesheet_" .
date("Y-m").".xls";
I can also
commit these
changes.<br>
- I would like
to "translate
calendar" when
displayed for
"Change the
date"<br>
but it seems
to be in js
file; it is
right?<br>
- What are the
goals of the
pages "submit
times" and
"supervisors"?<br>
<br>
Isabelle.<br>
<br>
------------------------------------------------------------------------------<br>
Forrester Wave
Report -
Recovery time
is now
measured in
hours and
minutes<br>
not days. Key
insights are
discussed in
the 2010
Forrester Wave
Report as<br>
part of an
in-depth
evaluation of
disaster
recovery
service
providers.<br>
Forrester
found the
best-in-class
provider in
terms of
services and
vision.<br>
Read this
report now! <a
moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo"
target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo" target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-04-13 13:49:46
|
---------- Forwarded message ---------- From: Scott Miller <sco...@gm...> Date: Wed, Apr 13, 2011 at 1:45 PM Subject: Re: [Tsheetx-developers] txsheet-2.0-demo: new commit for internationalization To: Mark Wrightson <ma...@rw...> Ah, I was not thinking about "mobile devices", so I saw no point in stretching things vertically. We could perhaps make two layouts, one for normal screens and another for mobile devices, is there an easy way to tell if a mobile device is viewing the page? The current version uses a 'text' field in the database which can hold up to 65535 characters, ie. 64kb. I'm fairly certain (but haven't verified) there is nothing in the code that cares how long a text message is, but it could be affected by the php max_post_size limitation. -Scott On Tue, Apr 12, 2011 at 10:26 PM, Mark Wrightson <ma...@rw...>wrote: > The way the current clocking form is, it is suitable for use on small > screens i.e. a smart phone which is a good feature. > The simple.php doesn't work well on a small screen due to width. Extended > descriptions with carriage returns aren't possible either in simple.php > whereas the other clocking methods allowed for carriage returns due to the > use of textareas instead of single row fields. > > I feel there is no need to cramp stuff up when there is no real > requirement. Simple.php needs to be all on single lines and that is fine, > but for normal clocking I can't see a reason why it needs to be so > slimline. If you take google calendars for example (see attached), > everything is nicely spread out. > > Maybe the message box restriction was in an old version of tsheetx > v1.2/v1.3 > I suppose you could set a limit but if we do then it should be at least > 1000chars, but then if there is no db limit then why bother? > > > > Regards > > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 12/04/2011 18:42, Scott Miller wrote: > > That was just an example, the sizes were very rough and adjustable. > Considering we now get 7 days of information on one line of the simple form, > I don't think we're so tight on space that we need to move to 3-5 lines for > each item on the daily page. I'd like to limit it to no more than two, the > simple form does currently have this as an option (long description). > > I can see adding a date field is needed, and with the new form I would like > to remove the clocking box altogether for this form. I am in agreement that > the message box should be restricted, but I don't believe there is a limit > of 255 characters in either the code or the database, so I'm curious as to > why longer messages are currently truncated? > > As for editing, I'm proposing you can edit multiple items at a time with > the form, so there would be no need for an "edit" link, but yes the 'x' > would be to delete the item. With a test user/test install, maybe play with > the simple form a bit to get a better idea of how the new daily form might > work? > > -Scott > > On Tue, Apr 12, 2011 at 5:18 PM, Mark Wrightson <ma...@rw...>wrote: > >> There are lots of inherent problems with using the simple timesheet in >> conjunction with other forms of time entry that I have always just disabled >> the simple view. >> >> I think for the daily view, more than one clock on/off isn't really >> required. The more elongated layout could cause issues as there won't be >> much room for the drop down menus if there is long strings, and the >> description being so small i don't think would work. >> >> A hybrid could work however? - Maybe: >> >> Client: >> [drop down] >> Message: >> [Message Box] >> Project: [drop down] >> Task: [drop down] >> Clock On: >> [12-4-2011 ] [8.00 AM] >> Clock off: >> [12-4-2011 ] [5.00 PM] >> [Clock on and/or off] >> >> >> >> >> >> Then rather than have the clocking box always visible at the top we could >> use a bit of javascript to make it appear - slide in from behind the menu >> for instance? >> One of the most annoying things i found was it took much longer to enter >> times than spanned a day boundary. If the dates are already in this form >> but preset to today's date, that would give users the opportunity to clock >> over day boundaries. The other thing that I found is that there should be >> validation on the message box to restrict it to 255 chars or change the db >> so this limit is removed as I sometimes entered rather long messages only to >> find that it was truncated at a later date. >> >> If you wanted to add lots of times could you do it as follows: >> Use my form as the entry method then have a button that you could click to >> add another clocking. The form above is then cleared and the data you >> previously entered is summarised as per Scott's image above it. the cross >> could be used to delete the time and another icon next to the cross could be >> added to edit the stored info. You would then need a final save btn: >> >> Maybe: >> >> Client1 >> Project1 >> Task 1 >> Description >> Times >> edit/delete >> Client 2 >> Project2 >> Task 2 >> Description 2 >> Times >> edit/delete >> >> >> >> >> >> Client: >> [drop down] >> Message: >> >> [Message Box] >> Project: [drop down] >> Task: [drop down] >> Clock On: >> [12-4-2011 ] [8.00 AM] >> Clock off: [12-4-2011 ] [5.00 PM] >> Add another clock >> Submit All! >> >> >> Cheers >> >> Mark >> >> _____________________________________________ >> >> Mob: 07725 695178 >> Email: ma...@rw... >> >> >> |
|
From: Mark W. <ma...@rw...> - 2011-04-12 22:26:31
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
The way the current clocking form is, it is suitable for use on
small screens i.e. a smart phone which is a good feature.<br>
The simple.php doesn't work well on a small screen due to width.
Extended descriptions with carriage returns aren't possible either
in simple.php whereas the other clocking methods allowed for
carriage returns due to the use of textareas instead of single row
fields.<br>
<br>
I feel there is no need to cramp stuff up when there is no real
requirement. Simple.php needs to be all on single lines and that is
fine, but for normal clocking I can't see a reason why it needs to
be so slimline. If you take google calendars for example (see
attached), everything is nicely spread out.<br>
<br>
Maybe the message box restriction was in an old version of tsheetx
v1.2/v1.3<br>
I suppose you could set a limit but if we do then it should be at
least 1000chars, but then if there is no db limit then why bother?<br>
<br>
<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 12/04/2011 18:42, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">That was just an example, the sizes were very rough
and adjustable. Considering we now get 7 days of information on
one line of the simple form, I don't think we're so tight on space
that we need to move to 3-5 lines for each item on the daily
page. I'd like to limit it to no more than two, the simple form
does currently have this as an option (long description).<br>
<br>
I can see adding a date field is needed, and with the new form I
would like to remove the clocking box altogether for this form. I
am in agreement that the message box should be restricted, but I
don't believe there is a limit of 255 characters in either the
code or the database, so I'm curious as to why longer messages are
currently truncated?<br>
<br>
As for editing, I'm proposing you can edit multiple items at a
time with the form, so there would be no need for an "edit" link,
but yes the 'x' would be to delete the item. With a test user/test
install, maybe play with the simple form a bit to get a better
idea of how the new daily form might work?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 5:18 PM, 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"> There are lots of
inherent problems with using the simple timesheet in
conjunction with other forms of time entry that I have
always just disabled the simple view.<br>
<br>
I think for the daily view, more than one clock on/off isn't
really required. The more elongated layout could cause
issues as there won't be much room for the drop down menus
if there is long strings, and the description being so small
i don't think would work.<br>
<br>
A hybrid could work however? - Maybe:<br>
<br>
<table border="1" cellpadding="2" cellspacing="2"
width="100%">
<tbody>
<tr>
<td valign="top">Client:<br>
</td>
<td valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="3" valign="top">Message:<br>
</td>
<td colspan="2" rowspan="3" valign="top">[Message Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td valign="top">[12-4-2011 ] [8.00 AM]<br>
</td>
<td valign="top">Clock off:<br>
</td>
<td rowspan="1" colspan="2" valign="top">[12-4-2011
] [5.00 PM]</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">[Clock on and/or off]<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
Then rather than have the clocking box always visible at the
top we could use a bit of javascript to make it appear -
slide in from behind the menu for instance?<br>
One of the most annoying things i found was it took much
longer to enter times than spanned a day boundary. If the
dates are already in this form but preset to today's date,
that would give users the opportunity to clock over day
boundaries. The other thing that I found is that there
should be validation on the message box to restrict it to
255 chars or change the db so this limit is removed as I
sometimes entered rather long messages only to find that it
was truncated at a later date.<br>
<br>
If you wanted to add lots of times could you do it as
follows:<br>
Use my form as the entry method then have a button that you
could click to add another clocking. The form above is then
cleared and the data you previously entered is summarised as
per Scott's image above it. the cross could be used to
delete the time and another icon next to the cross could be
added to edit the stored info. You would then need a final
save btn:<br>
<br>
Maybe:<br>
<br>
<table border="1" cellpadding="2" cellspacing="2"
width="100%">
<tbody>
<tr>
<td valign="top">Client1<br>
</td>
<td valign="top">Project1<br>
</td>
<td valign="top">Task 1<br>
</td>
<td valign="top">Description<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top">Client 2<br>
</td>
<td valign="top">Project2<br>
</td>
<td valign="top">Task 2<br>
</td>
<td valign="top">Description 2<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td colspan="2" rowspan="1" valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Client:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="4" valign="top">Message:<br>
<br>
</td>
<td colspan="2" rowspan="4" valign="top">[Message Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td colspan="2" rowspan="1" valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td colspan="2" rowspan="1" valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [8.00 AM]<br>
</td>
</tr>
<tr>
<td valign="top">Clock off: </td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011
] [5.00 PM] </td>
<td valign="top"><br>
</td>
<td valign="top">Add another clock <br>
</td>
<td valign="top">Submit All!<br>
</td>
</tr>
</tbody>
</table>
<div class="im"> <br>
<br>
Cheers<br>
<br>
Mark<br>
<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>
<br>
</div>
<div>
<div class="h5"> On 12/04/2011 17:11, Scott Miller wrote:
<blockquote type="cite">Ok, so, I'm thinking about
redesigning the daily time entry form(s). Several
months ago someone (may have been you, Mark) asked
about changing the simple form to have people record
starting and ending times, and I vehemently disagree
with doing that, but, remembering that got me thinking
that perhaps the daily form should look more like the
simple form.<br>
<br>
The vision I currently have is something like the
attached image, where you have the
client/project/task description, then some radio
buttons to clock on and off now, as well as time
start/stop entry areas. We could then remove the
whole "pop up" dialog thing currently at the top of
the page.<br>
<br>
How does this sound? can we improve this form even
more?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 2:48
PM, 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;">Hey Mark,<br>
<br>
I'm going to add my answers to the middle of your
text below:<br>
<br>
<div class="gmail_quote">
<div>On Mon, Apr 11, 2011 at 10:50 PM, Mark
Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> Ah ok
fair enough. Just wondering - do you
think it would be a good idea to get all
the forms working again and get to a point
where we know the core functionality works
again before we do much more redesigning??<br>
</div>
</blockquote>
</div>
<div><font color="#339999"><br>
</font>
<div style="margin-left: 40px; color: rgb(0,
0, 153);">I think it depends on the
situation. If we want to redesign
something, now's the time to do it, so why
waste time fixing some area that you're
planning to completely redo? If you're not
planning to redo an area, then, yes, getting
those forms to work again would be working
toward the end goal :-)<br>
</div>
</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 bgcolor="#ffffff" text="#000000"> <br>
I'm not going to be able to do very much
atall over the next couple of months as it
is "all hands on deck" to get my
disertation done. On another note I have
pretty much completed a upgrade system.
It does the following interactively:<br>
<br>
1. backup of db<br>
2.checks for any prerequisites<br>
3. performs db updates<br>
4. complete<br>
<br>
The only problem I currently have is that
it works fantastically when moving from
version v1.5.3 to v1.5.4 or even v1.5.3
to v1.6.0 as long as it is a single jump.
I can't currently handle: v1.5.3 to v1.5.4
to v1.6.0.<br>
<br>
an upgrade basically consists of a new
class file called for example:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
so another file could be created i.e.<br>
upgradev1_5_3_to_v1_6_0.class.php in which
case only a single upgrade step<br>
is required and that will work fine (but
starts to get labour intensive creating
files for every permutation).<br>
<br>
I've written a script that can work out
the necessary upgrade path i.e. <br>
going from v1.5.3 to v1.6.0<br>
run the following upgrades:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
upgradev1_5_4_to_v1_6_0.class.php<br>
<br>
But this is the point where I stopped as I
was slightly concerned that if the
database version is 1.5.3 and the code
version is 1.6.0 and the code base had
changed significantly in 1.6.0 there is
then a possibility some of the code in the
class file
"upgradev1_5_3_to_v1_5_4.class.php" would
no longer work correctly. <br>
<br>
Have you got any thoughts on this
problem? <br>
</div>
</blockquote>
</div>
<div><br>
<div style="margin-left: 40px; color: rgb(51,
102, 102);"><span style="color: rgb(0, 0,
153);"> Running each step is the way to
go. Modifying the database, since we
shouldn't be looking to the databases for
much more than the version number during
the upgrade, it shouldn't ever matter what
information is in the database while
moving from one version through however
many upgrade files as needed to get to
what the current database schema should
look like. As long as each step is valid,
you should be able to go through all the
steps. This is how the upgrade process
has worked in the past.</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">Although
it is tempting to write upgrade scripts
that are able to jump from a past version
directly to the new version, this is not
recommended because, as you've discovered
it makes loads more work for future
upgrades.</span><br style="color: rgb(0,
0, 153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">The
upgrade should not attempt to figure out
what code files need to be
changed/added/deleted. The upgrade
process should look like this:</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">1. Old
installation with old database</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">2.
download new version</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">3.
unpack the new version</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">4.
rename the old version's directory
something different: tsx -> tsx.old
or use version numbers or whatever</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">5. move
the new unpacked version to the original
directory's name</span><br style="color:
rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">6.
optionally copy a configuration file or
two from the old system to the new system
to assist with the upgrade</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">6. open
a web browser to the site</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">In this
way, the new version should be a
completely clean upgrade, so the only work
that needs to be accomplished is the
upgrading of the database.</span><br>
</div>
<br>
</div>
<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 bgcolor="#ffffff" text="#000000">
Cheers
<div><br>
Mark<br>
<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>
<br>
</div>
<div>
<div> On 11/04/2011 23:33, Scott
Miller wrote:
<blockquote type="cite">I had
managed to wrap my brain around
most of it last Friday, but I
didn't get a chance to mess with
it today. <br>
<br>
I'm actually toying with totally
redesigning the daily form, I'll
try to email you tomorrow
detailing some ideas I had to
redesign it, and we can bat it
back and forth.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Mon,
Apr 11, 2011 at 10:30 PM, Mark
Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> Hi Scott, <br>
<br>
The "quite broken" aspect is
probably to do with the OO
updates. Can i help atall??<br>
<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> <br>
On 11/04/2011 21:05,
Scott Miller wrote:
<blockquote type="cite">Hey
Isabelle, I am also
attempting to work on
the clockOnOff stuff,
as it appears to be
quite broken...<br>
<br>
Yes the "change the
date" stuff is in
Javascript, but that
doesn't mean we can't
embed PHP within the
java stuff, but I
would also like to
enhance, or even
replace that whole
area of the new
system, so,
internationalizing
that would probably be
premature at this
point.<br>
<br>
The submit times and
supervisors stuff are
the "not ready for
prime time" attempts
at a submission &
approval system for
the timesheet system.
Again,
internationalization
of this area is
probably premature...<br>
<br>
I would love to see
the excel system name
changes you've made,
go ahead and submit
that.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Mon, Apr 11, 2011 at
7:43 PM, Isabelle
Vergely <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ver...@fr..." target="_blank">ver...@fr...</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;">Hello,<br>
<br>
My today commit on
Directory
branches/txsheet-2.0-demo/(=>
Revision 293)<br>
------------------------------------------------------------------------<br>
- Modifications
for
internationalization:<br>
* en-GB.ini,
fr-FR.ini<br>
* clockOnOff.inc,
clockOnOff_core_new.inc,
clock_popup.php,
stopwatch.php<br>
* template.php,
common.class.php,
footer.inc<br>
* absences.php,
monthly.php,
simple.php,
weekly.php<br>
- Small
modification in
timesheet.css<br>
<br>
Questions on
txsheet-2.0-demo:<br>
------------------------------<br>
- I have also made
changes for excel
filenames more
representative
than<br>
"Timesheet_" .
date("Y-m").".xls";
I can also commit
these changes.<br>
- I would like to
"translate
calendar" when
displayed for
"Change the date"<br>
but it seems to be
in js file; it is
right?<br>
- What are the
goals of the pages
"submit times" and
"supervisors"?<br>
<br>
Isabelle.<br>
<br>
------------------------------------------------------------------------------<br>
Forrester Wave
Report - Recovery
time is now
measured in hours
and minutes<br>
not days. Key
insights are
discussed in the
2010 Forrester
Wave Report as<br>
part of an
in-depth
evaluation of
disaster recovery
service providers.<br>
Forrester found
the best-in-class
provider in terms
of services and
vision.<br>
Read this report
now! <a
moz-do-not-send="true"
href="http://p.sf.net/sfu/ibm-webcastpromo" target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo" target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-04-12 17:42:45
|
That was just an example, the sizes were very rough and adjustable.
Considering we now get 7 days of information on one line of the simple form,
I don't think we're so tight on space that we need to move to 3-5 lines for
each item on the daily page. I'd like to limit it to no more than two, the
simple form does currently have this as an option (long description).
I can see adding a date field is needed, and with the new form I would like
to remove the clocking box altogether for this form. I am in agreement that
the message box should be restricted, but I don't believe there is a limit
of 255 characters in either the code or the database, so I'm curious as to
why longer messages are currently truncated?
As for editing, I'm proposing you can edit multiple items at a time with the
form, so there would be no need for an "edit" link, but yes the 'x' would be
to delete the item. With a test user/test install, maybe play with the
simple form a bit to get a better idea of how the new daily form might work?
-Scott
On Tue, Apr 12, 2011 at 5:18 PM, Mark Wrightson <ma...@rw...>wrote:
> There are lots of inherent problems with using the simple timesheet in
> conjunction with other forms of time entry that I have always just disabled
> the simple view.
>
> I think for the daily view, more than one clock on/off isn't really
> required. The more elongated layout could cause issues as there won't be
> much room for the drop down menus if there is long strings, and the
> description being so small i don't think would work.
>
> A hybrid could work however? - Maybe:
>
> Client:
> [drop down]
> Message:
> [Message Box]
> Project: [drop down]
> Task: [drop down]
> Clock On:
> [12-4-2011 ] [8.00 AM]
> Clock off:
> [12-4-2011 ] [5.00 PM]
> [Clock on and/or off]
>
>
>
>
>
> Then rather than have the clocking box always visible at the top we could
> use a bit of javascript to make it appear - slide in from behind the menu
> for instance?
> One of the most annoying things i found was it took much longer to enter
> times than spanned a day boundary. If the dates are already in this form
> but preset to today's date, that would give users the opportunity to clock
> over day boundaries. The other thing that I found is that there should be
> validation on the message box to restrict it to 255 chars or change the db
> so this limit is removed as I sometimes entered rather long messages only to
> find that it was truncated at a later date.
>
> If you wanted to add lots of times could you do it as follows:
> Use my form as the entry method then have a button that you could click to
> add another clocking. The form above is then cleared and the data you
> previously entered is summarised as per Scott's image above it. the cross
> could be used to delete the time and another icon next to the cross could be
> added to edit the stored info. You would then need a final save btn:
>
> Maybe:
>
> Client1
> Project1
> Task 1
> Description
> Times
> edit/delete
> Client 2
> Project2
> Task 2
> Description 2
> Times
> edit/delete
>
>
>
>
>
> Client:
> [drop down]
> Message:
>
> [Message Box]
> Project: [drop down]
> Task: [drop down]
> Clock On:
> [12-4-2011 ] [8.00 AM]
> Clock off: [12-4-2011 ] [5.00 PM]
> Add another clock
> Submit All!
>
>
> Cheers
>
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 12/04/2011 17:11, Scott Miller wrote:
>
> Ok, so, I'm thinking about redesigning the daily time entry form(s).
> Several months ago someone (may have been you, Mark) asked about changing
> the simple form to have people record starting and ending times, and I
> vehemently disagree with doing that, but, remembering that got me thinking
> that perhaps the daily form should look more like the simple form.
>
> The vision I currently have is something like the attached image, where you
> have the client/project/task description, then some radio buttons to clock
> on and off now, as well as time start/stop entry areas. We could then
> remove the whole "pop up" dialog thing currently at the top of the page.
>
> How does this sound? can we improve this form even more?
>
> -Scott
>
> On Tue, Apr 12, 2011 at 2:48 PM, Scott Miller <sco...@gm...>wrote:
>
>> Hey Mark,
>>
>> I'm going to add my answers to the middle of your text below:
>>
>> On Mon, Apr 11, 2011 at 10:50 PM, Mark Wrightson <
>> ma...@rw...> wrote:
>>
>>> Ah ok fair enough. Just wondering - do you think it would be a good
>>> idea to get all the forms working again and get to a point where we know the
>>> core functionality works again before we do much more redesigning??
>>>
>>
>> I think it depends on the situation. If we want to redesign something,
>> now's the time to do it, so why waste time fixing some area that you're
>> planning to completely redo? If you're not planning to redo an area, then,
>> yes, getting those forms to work again would be working toward the end goal
>> :-)
>>
>>>
>>> I'm not going to be able to do very much atall over the next couple of
>>> months as it is "all hands on deck" to get my disertation done. On another
>>> note I have pretty much completed a upgrade system. It does the following
>>> interactively:
>>>
>>> 1. backup of db
>>> 2.checks for any prerequisites
>>> 3. performs db updates
>>> 4. complete
>>>
>>> The only problem I currently have is that it works fantastically when
>>> moving from version v1.5.3 to v1.5.4 or even v1.5.3 to v1.6.0 as long as it
>>> is a single jump. I can't currently handle: v1.5.3 to v1.5.4 to v1.6.0.
>>>
>>> an upgrade basically consists of a new class file called for example:
>>> upgradev1_5_3_to_v1_5_4.class.php
>>> so another file could be created i.e.
>>> upgradev1_5_3_to_v1_6_0.class.php in which case only a single upgrade
>>> step
>>> is required and that will work fine (but starts to get labour intensive
>>> creating files for every permutation).
>>>
>>> I've written a script that can work out the necessary upgrade path i.e.
>>> going from v1.5.3 to v1.6.0
>>> run the following upgrades:
>>> upgradev1_5_3_to_v1_5_4.class.php
>>> upgradev1_5_4_to_v1_6_0.class.php
>>>
>>> But this is the point where I stopped as I was slightly concerned that if
>>> the database version is 1.5.3 and the code version is 1.6.0 and the code
>>> base had changed significantly in 1.6.0 there is then a possibility some of
>>> the code in the class file "upgradev1_5_3_to_v1_5_4.class.php" would no
>>> longer work correctly.
>>>
>>> Have you got any thoughts on this problem?
>>>
>>
>> Running each step is the way to go. Modifying the database, since we
>> shouldn't be looking to the databases for much more than the version number
>> during the upgrade, it shouldn't ever matter what information is in the
>> database while moving from one version through however many upgrade files as
>> needed to get to what the current database schema should look like. As long
>> as each step is valid, you should be able to go through all the steps. This
>> is how the upgrade process has worked in the past.
>>
>> Although it is tempting to write upgrade scripts that are able to jump
>> from a past version directly to the new version, this is not recommended
>> because, as you've discovered it makes loads more work for future upgrades.
>>
>> The upgrade should not attempt to figure out what code files need to be
>> changed/added/deleted. The upgrade process should look like this:
>>
>> 1. Old installation with old database
>> 2. download new version
>> 3. unpack the new version
>> 4. rename the old version's directory something different: tsx ->
>> tsx.old or use version numbers or whatever
>> 5. move the new unpacked version to the original directory's name
>> 6. optionally copy a configuration file or two from the old system to the
>> new system to assist with the upgrade
>> 6. open a web browser to the site
>>
>> In this way, the new version should be a completely clean upgrade, so the
>> only work that needs to be accomplished is the upgrading of the database.
>>
>> Cheers
>>>
>>> Mark
>>>
>>> _____________________________________________
>>>
>>> Mob: 07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 11/04/2011 23:33, Scott Miller wrote:
>>>
>>> I had managed to wrap my brain around most of it last Friday, but I
>>> didn't get a chance to mess with it today.
>>>
>>> I'm actually toying with totally redesigning the daily form, I'll try to
>>> email you tomorrow detailing some ideas I had to redesign it, and we can bat
>>> it back and forth.
>>>
>>> -Scott
>>>
>>> On Mon, Apr 11, 2011 at 10:30 PM, Mark Wrightson <
>>> ma...@rw...> wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> The "quite broken" aspect is probably to do with the OO updates. Can i
>>>> help atall??
>>>>
>>>> Mark
>>>>
>>>> _____________________________________________
>>>>
>>>> Mob: 07725 695178
>>>> Email: ma...@rw...
>>>>
>>>>
>>>> On 11/04/2011 21:05, Scott Miller wrote:
>>>>
>>>> Hey Isabelle, I am also attempting to work on the clockOnOff stuff, as
>>>> it appears to be quite broken...
>>>>
>>>> Yes the "change the date" stuff is in Javascript, but that doesn't mean
>>>> we can't embed PHP within the java stuff, but I would also like to enhance,
>>>> or even replace that whole area of the new system, so, internationalizing
>>>> that would probably be premature at this point.
>>>>
>>>> The submit times and supervisors stuff are the "not ready for prime
>>>> time" attempts at a submission & approval system for the timesheet system.
>>>> Again, internationalization of this area is probably premature...
>>>>
>>>> I would love to see the excel system name changes you've made, go ahead
>>>> and submit that.
>>>>
>>>> -Scott
>>>>
>>>> On Mon, Apr 11, 2011 at 7:43 PM, Isabelle Vergely <
>>>> ver...@fr...> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> My today commit on Directory branches/txsheet-2.0-demo/(=> Revision
>>>>> 293)
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> - Modifications for internationalization:
>>>>> * en-GB.ini, fr-FR.ini
>>>>> * clockOnOff.inc, clockOnOff_core_new.inc, clock_popup.php,
>>>>> stopwatch.php
>>>>> * template.php, common.class.php, footer.inc
>>>>> * absences.php, monthly.php, simple.php, weekly.php
>>>>> - Small modification in timesheet.css
>>>>>
>>>>> Questions on txsheet-2.0-demo:
>>>>> ------------------------------
>>>>> - I have also made changes for excel filenames more representative than
>>>>> "Timesheet_" . date("Y-m").".xls"; I can also commit these changes.
>>>>> - I would like to "translate calendar" when displayed for "Change the
>>>>> date"
>>>>> but it seems to be in js file; it is right?
>>>>> - What are the goals of the pages "submit times" and "supervisors"?
>>>>>
>>>>> Isabelle.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Forrester Wave Report - Recovery time is now measured in hours and
>>>>> minutes
>>>>> not days. Key insights are discussed in the 2010 Forrester Wave Report
>>>>> as
>>>>> part of an in-depth evaluation of disaster recovery service providers.
>>>>> Forrester found the best-in-class provider in terms of services and
>>>>> vision.
>>>>> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
>>>>> _______________________________________________
>>>>> Tsheetx-developers mailing list
>>>>> Tsh...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Forrester Wave Report - Recovery time is now measured in hours and minutes
>>>> not days. Key insights are discussed in the 2010 Forrester Wave Report as
>>>> part of an in-depth evaluation of disaster recovery service providers.
>>>> Forrester found the best-in-class provider in terms of services and vision.
>>>> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
>>>>
>>>>
>>>> _______________________________________________
>>>> Tsheetx-developers mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>
>>>>
>>>
>>
>
|
|
From: Mark W. <ma...@rw...> - 2011-04-12 17:19:03
|
<!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">
There are lots of inherent problems with using the simple timesheet
in conjunction with other forms of time entry that I have always
just disabled the simple view.<br>
<br>
I think for the daily view, more than one clock on/off isn't really
required. The more elongated layout could cause issues as there
won't be much room for the drop down menus if there is long strings,
and the description being so small i don't think would work.<br>
<br>
A hybrid could work however? - Maybe:<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client:<br>
</td>
<td valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="3" valign="top">Message:<br>
</td>
<td colspan="2" rowspan="3" valign="top">[Message Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td valign="top">[12-4-2011 ] [8.00 AM]<br>
</td>
<td valign="top">Clock off:<br>
</td>
<td rowspan="1" colspan="2" valign="top">[12-4-2011 ]
[5.00 PM]</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">[Clock on and/or off]<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
Then rather than have the clocking box always visible at the top we
could use a bit of javascript to make it appear - slide in from
behind the menu for instance?<br>
One of the most annoying things i found was it took much longer to
enter times than spanned a day boundary. If the dates are already
in this form but preset to today's date, that would give users the
opportunity to clock over day boundaries. The other thing that I
found is that there should be validation on the message box to
restrict it to 255 chars or change the db so this limit is removed
as I sometimes entered rather long messages only to find that it was
truncated at a later date.<br>
<br>
If you wanted to add lots of times could you do it as follows:<br>
Use my form as the entry method then have a button that you could
click to add another clocking. The form above is then cleared and
the data you previously entered is summarised as per Scott's image
above it. the cross could be used to delete the time and another
icon next to the cross could be added to edit the stored info. You
would then need a final save btn:<br>
<br>
Maybe:<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Client1<br>
</td>
<td valign="top">Project1<br>
</td>
<td valign="top">Task 1<br>
</td>
<td valign="top">Description<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top">Client 2<br>
</td>
<td valign="top">Project2<br>
</td>
<td valign="top">Task 2<br>
</td>
<td valign="top">Description 2<br>
</td>
<td valign="top">Times<br>
</td>
<td valign="top">edit/delete<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td colspan="2" rowspan="1" valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Client:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[drop down]<br>
</td>
<td colspan="1" rowspan="4" valign="top">Message:<br>
<br>
</td>
<td colspan="2" rowspan="4" valign="top">[Message Box]<br>
</td>
</tr>
<tr>
<td valign="top">Project:</td>
<td colspan="2" rowspan="1" valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Task:</td>
<td colspan="2" rowspan="1" valign="top">[drop down]<br>
</td>
</tr>
<tr>
<td valign="top">Clock On:<br>
</td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011 ]
[8.00 AM]<br>
</td>
</tr>
<tr>
<td valign="top">Clock off: </td>
<td colspan="2" rowspan="1" valign="top">[12-4-2011 ]
[5.00 PM] </td>
<td valign="top"><br>
</td>
<td valign="top">Add another clock <br>
</td>
<td valign="top">Submit All!<br>
</td>
</tr>
</tbody>
</table>
<br>
<br>
Cheers<br>
<br>
Mark<br>
<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 12/04/2011 17:11, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">Ok, so, I'm thinking about redesigning the daily time
entry form(s). Several months ago someone (may have been you,
Mark) asked about changing the simple form to have people record
starting and ending times, and I vehemently disagree with doing
that, but, remembering that got me thinking that perhaps the daily
form should look more like the simple form.<br>
<br>
The vision I currently have is something like the attached image,
where you have the client/project/task description, then some
radio buttons to clock on and off now, as well as time start/stop
entry areas. We could then remove the whole "pop up" dialog thing
currently at the top of the page.<br>
<br>
How does this sound? can we improve this form even more?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Apr 12, 2011 at 2:48 PM, 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;">Hey Mark,<br>
<br>
I'm going to add my answers to the middle of your text below:<br>
<br>
<div class="gmail_quote">
<div class="im">On Mon, Apr 11, 2011 at 10:50 PM, Mark
Wrightson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">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"> Ah ok fair
enough. Just wondering - do you think it would be a
good idea to get all the forms working again and get
to a point where we know the core functionality works
again before we do much more redesigning??<br>
</div>
</blockquote>
</div>
<div><font color="#339999"><br>
</font>
<div style="margin-left: 40px; color: rgb(0, 0, 153);">I
think it depends on the situation. If we want to
redesign something, now's the time to do it, so why
waste time fixing some area that you're planning to
completely redo? If you're not planning to redo an
area, then, yes, getting those forms to work again would
be working toward the end goal :-)<br>
</div>
</div>
<div class="im">
<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"> <br>
I'm not going to be able to do very much atall over
the next couple of months as it is "all hands on deck"
to get my disertation done. On another note I have
pretty much completed a upgrade system. It does the
following interactively:<br>
<br>
1. backup of db<br>
2.checks for any prerequisites<br>
3. performs db updates<br>
4. complete<br>
<br>
The only problem I currently have is that it works
fantastically when moving from version v1.5.3 to
v1.5.4 or even v1.5.3 to v1.6.0 as long as it is a
single jump. I can't currently handle: v1.5.3 to
v1.5.4 to v1.6.0.<br>
<br>
an upgrade basically consists of a new class file
called for example:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
so another file could be created i.e.<br>
upgradev1_5_3_to_v1_6_0.class.php in which case only a
single upgrade step<br>
is required and that will work fine (but starts to get
labour intensive creating files for every
permutation).<br>
<br>
I've written a script that can work out the necessary
upgrade path i.e. <br>
going from v1.5.3 to v1.6.0<br>
run the following upgrades:<br>
upgradev1_5_3_to_v1_5_4.class.php<br>
upgradev1_5_4_to_v1_6_0.class.php<br>
<br>
But this is the point where I stopped as I was
slightly concerned that if the database version is
1.5.3 and the code version is 1.6.0 and the code base
had changed significantly in 1.6.0 there is then a
possibility some of the code in the class file
"upgradev1_5_3_to_v1_5_4.class.php" would no longer
work correctly. <br>
<br>
Have you got any thoughts on this problem? <br>
</div>
</blockquote>
</div>
<div><br>
<div style="margin-left: 40px; color: rgb(51, 102, 102);"><span
style="color: rgb(0, 0, 153);"> Running each step is
the way to go. Modifying the database, since we
shouldn't be looking to the databases for much more
than the version number during the upgrade, it
shouldn't ever matter what information is in the
database while moving from one version through however
many upgrade files as needed to get to what the
current database schema should look like. As long as
each step is valid, you should be able to go through
all the steps. This is how the upgrade process has
worked in the past.</span><br style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">Although it is
tempting to write upgrade scripts that are able to
jump from a past version directly to the new version,
this is not recommended because, as you've discovered
it makes loads more work for future upgrades.</span><br
style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">The upgrade should
not attempt to figure out what code files need to be
changed/added/deleted. The upgrade process should
look like this:</span><br style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">1. Old installation
with old database</span><br style="color: rgb(0, 0,
153);">
<span style="color: rgb(0, 0, 153);">2. download new
version</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">3. unpack the new
version</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">4. rename the old
version's directory something different: tsx ->
tsx.old or use version numbers or whatever</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">5. move the new
unpacked version to the original directory's name</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">6. optionally copy
a configuration file or two from the old system to the
new system to assist with the upgrade</span><br
style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">6. open a web
browser to the site</span><br style="color: rgb(0, 0,
153);">
<br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);">In this way, the
new version should be a completely clean upgrade, so
the only work that needs to be accomplished is the
upgrading of the database.</span><br>
</div>
<br>
</div>
<div>
<div class="h5">
<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"> Cheers
<div><br>
Mark<br>
<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>
<br>
</div>
<div>
<div> On 11/04/2011 23:33, Scott Miller wrote:
<blockquote type="cite">I had managed to wrap my
brain around most of it last Friday, but I
didn't get a chance to mess with it today. <br>
<br>
I'm actually toying with totally redesigning
the daily form, I'll try to email you tomorrow
detailing some ideas I had to redesign it, and
we can bat it back and forth.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Mon, Apr 11, 2011
at 10:30 PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">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"> Hi
Scott, <br>
<br>
The "quite broken" aspect is probably to
do with the OO updates. Can i help
atall??<br>
<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> <br>
On 11/04/2011 21:05, Scott Miller
wrote:
<blockquote type="cite">Hey
Isabelle, I am also attempting to
work on the clockOnOff stuff, as
it appears to be quite broken...<br>
<br>
Yes the "change the date" stuff is
in Javascript, but that doesn't
mean we can't embed PHP within the
java stuff, but I would also like
to enhance, or even replace that
whole area of the new system, so,
internationalizing that would
probably be premature at this
point.<br>
<br>
The submit times and supervisors
stuff are the "not ready for prime
time" attempts at a submission
& approval system for the
timesheet system. Again,
internationalization of this area
is probably premature...<br>
<br>
I would love to see the excel
system name changes you've made,
go ahead and submit that.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Mon,
Apr 11, 2011 at 7:43 PM,
Isabelle Vergely <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ver...@fr..."
target="_blank">ver...@fr...</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;">Hello,<br>
<br>
My today commit on Directory
branches/txsheet-2.0-demo/(=>
Revision 293)<br>
------------------------------------------------------------------------<br>
- Modifications for
internationalization:<br>
* en-GB.ini, fr-FR.ini<br>
* clockOnOff.inc,
clockOnOff_core_new.inc,
clock_popup.php, stopwatch.php<br>
* template.php,
common.class.php, footer.inc<br>
* absences.php, monthly.php,
simple.php, weekly.php<br>
- Small modification in
timesheet.css<br>
<br>
Questions on txsheet-2.0-demo:<br>
------------------------------<br>
- I have also made changes for
excel filenames more
representative than<br>
"Timesheet_" .
date("Y-m").".xls"; I can also
commit these changes.<br>
- I would like to "translate
calendar" when displayed for
"Change the date"<br>
but it seems to be in js file;
it is right?<br>
- What are the goals of the
pages "submit times" and
"supervisors"?<br>
<br>
Isabelle.<br>
<br>
------------------------------------------------------------------------------<br>
Forrester Wave Report -
Recovery time is now measured
in hours and minutes<br>
not days. Key insights are
discussed in the 2010
Forrester Wave Report as<br>
part of an in-depth evaluation
of disaster recovery service
providers.<br>
Forrester found the
best-in-class provider in
terms of services and vision.<br>
Read this report now! <a
moz-do-not-send="true"
href="http://p.sf.net/sfu/ibm-webcastpromo"
target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" href="http://p.sf.net/sfu/ibm-webcastpromo" target="_blank">http://p.sf.net/sfu/ibm-webcastpromo</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>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-04-12 14:26:18
|
Hey Peter, The daily, simple, weekly and monthly views, and the client/project/task editing areas have all been "internationalized" at this point, so looking at those files would be a good place to start. -Scott On Tue, Apr 12, 2011 at 4:45 AM, Peter Lazarus <pal...@gm...> wrote: > Hi Isabelle, > I'm working on the submit times and supervisors stuff. The idea behind > these functions is to have a weekly timesheet submission process. Once a > user has entered his times for the week and is happy with them, he can > submit them to his manager for approval. > > So these functions are partly implemented and require some more work. At > this time it would be good for me to change them to make > internationalisation later on much easier. Which module do you suggest I > look at to understand the way I should provide the basis for > internationalising these functions? > > Peter > > > On 04/12/2011 06:05 AM, Scott Miller wrote: > >> Hey Isabelle, I am also attempting to work on the clockOnOff stuff, as it >> appears to be quite broken... >> >> Yes the "change the date" stuff is in Javascript, but that doesn't mean we >> can't embed PHP within the java stuff, but I would also like to enhance, or >> even replace that whole area of the new system, so, internationalizing that >> would probably be premature at this point. >> >> The submit times and supervisors stuff are the "not ready for prime time" >> attempts at a submission & approval system for the timesheet system. Again, >> internationalization of this area is probably premature... >> >> I would love to see the excel system name changes you've made, go ahead >> and submit that. >> >> -Scott >> > |
|
From: Scott M. <sco...@gm...> - 2011-04-12 14:23:45
|
Hi Esteban, We would love for you to get involved. Prerequisites for those who want to help: You need some basic understanding of Subversion: How to check things out: svn co https://tsheetx.svn.sourceforge.net/svnroot/tsheetx/branches/txsheet-2.0-demo/ How to check things in: svn ci -m "some explaination of what you've done" --username=<your username> How to stay up-to-date with the code: svn update You need a sourceforge user account, then you'll need to let us know what your username is so we can add you to the list of people allowed to check things in via subversion. If you don't have a sourceforge account yet, register yourself here: https://sourceforge.net/account/registration/ Adding new languages: We've borrowed the model for translations from the Joomla project. I would suggest reading over the documentation they have, however when I went to find the information just now, it appears that their documentation is in the middle of some major rework, so the information is not easily found, and it seems to be pretty scattered. Essentially, my best advice is to take a copy of one language sub directory, and copy it to a new language sub directory, and start modifying things as needed. Installation: The installation scripts are currently not fully functional, so it will take some determination and good skills on your part to get the packages installed and functional so you can start to work. This isn't meant to try to scare you off, we'll be happy to attempt to help you if you get stuck, but I don't want there to be inappropriate expectations that this will be very simple. Getting your new language to display: You'll need to muck with some of the areas that eventually will determine what language it should be using. The html headers need to be modified, and the currently hard coded language settings in the jclasses factory and jclasses languages files. I hope this helps, don't hesitate to ask us if you get stuck somewhere. -Scott 2011/4/11 Esteban Monge <est...@gm...> > Sorry... I send correctly > > > Long time ago I want help with translations to spanish, If you teach me how > make the translations via svn o another I can made for spanish. > > Timesheet is very usefull for my, I want retribuite something > > > -- > http://www.nuevaeralatam.com > Linux user number 478378 > Linux machine number 386687 > Tec. Esteban Monge Marín > Tel: (506) 8379-3562 > > “No habrá manera de desarrollarnos y salir de > la pobreza mientras los pocos negocios > grandes de nuestro medio se entreguen a las > economías foráneas y nosotros nos > quedemos con solo negocios de pobre, > mientras en vez de ser propietarios de nuestro > propio país nos convirtamos en un ejército de > empleados del exterior” > José Figueres Ferrer, 1952. > > > > ------------------------------------------------------------------------------ > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
|
From: Mark W. <ma...@rw...> - 2011-04-12 11:18:10
|
<!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">
There is another method that can be used that has a similar effect.<br>
<br>
PageElements::setTemplate('popup_template.php');<br>
<br>
This changes the template that will be used within the current
theme.<br>
I have added a popup template to the tsheetx theme and applied it to
stopwatch.<br>
<br>
Well done to the person who has started to tackle the stopwatch OO
update. I've been leaving that one for a while!<br>
<br>
This setTemplate needs to be applied to all the popup windows that
we use.<br>
<br>
Kind Regards<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 12/04/2011 11:11, Peter Lazarus wrote:
<blockquote cite="mid:4DA...@gm..." type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Too brilliant!!<br>
<br>
On 04/12/2011 05:57 PM, Mark Wrightson wrote:
<blockquote cite="mid:4DA...@rw..."
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Peter & Everyone else actually, <br>
<br>
If you need to specify a different theme for a particular page,
this is very easy to achieve. Just create a new theme in the
themes folder (copy the tsx theme and modify is the best
recommendation).<br>
<br>
Once you've created your theme and you want to apply to it a
specific page just add the following line of code to the top of
the file in question i.e. monthly.php:<br>
<br>
PageElements::setTheme('diffTheme');<br>
<br>
where diffTheme is the folder name of the different theme.<br>
<br>
Hope this helps!<br>
<br>
Regards<br>
Mark Wrightson<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 12/04/2011 05:57, Peter Lazarus wrote:
<blockquote cite="mid:4DA...@gm..." type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi all,<br>
this is to bring you up to date with what I have accomplished
so far in cleaning up the html and moving formattiing into css
style sheets. To sum it up, not much has been achieved so far.<br>
<br>
What I have done is to work on the submit.php form. In order
to clean up the html I built an entirely new web page in a web
page editor to get the formatting right. Now that that's been
mostly achieved, I then applied the changes back into
submit.new.php which is a copy of the existing submit.php. I
chose submit.php because its a relatively uncomplicated
layout, and because it's layout is in common with or similar
to many of the reports.<br>
<br>
The problem I now face is applying the css styling across the
rest of the forms. That will require some effort and tweaking.
Hence it will take some time. Also I don't think I can submit
any of my changes until all forms have been changed. This is
because the link to the style sheet ( <<span
class="start-tag">link</span><span class="attribute-name">
rel</span>=<span class="attribute-value">"stylesheet" </span><span
class="attribute-name">href</span><span>="</span><a
moz-do-not-send="true"
href="view-source:http://localhost/tsheetxdemo/themes/txsheet/styles/timesheet.css">/tsheetxdemo/themes/txsheet/styles/timesheet.css</a><span>"
</span><span class="attribute-name">type</span>=<span
class="attribute-value">"text/css" </span><span
class="error"><span class="attribute-name">/</span></span>>)
is found in the header and that's part of Mark's common
routines. I don't think I can even link to a new css sheet
ahead of the existing links because there will be bits of the
existing style sheets that will interfere with the new one.
So, any suggestions or ideas on how I can get round that
problem?<br>
<br>
regards<br>
Peter<br>
<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ibm-webcastpromo">http://p.sf.net/sfu/ibm-webcastpromo</a></pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a moz-do-not-send="true" 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>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/ibm-webcastpromo">http://p.sf.net/sfu/ibm-webcastpromo</a></pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a moz-do-not-send="true" 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>
</blockquote>
</body>
</html>
|
29 messages has been excluded from this view by a project administrator.
