Menu
▾
▴
tsheetx-developers
|
From: Isabelle V. <ver...@fr...> - 2011-04-11 19:43:38
|
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.
|
|
From: Scott M. <sco...@gm...> - 2011-04-11 20:05:14
|
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
>
|
|
From: Esteban M. <est...@gm...> - 2011-04-11 23:50:26
|
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. |
|
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: Peter L. <pal...@gm...> - 2011-04-12 04:45:17
|
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: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: 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:BANLkTinbHwtJVJKp03pHFdVhFkQ2O3ph=w...@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: 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:BANLkTinbHwtJVJKp03pHFdVhFkQ2O3ph=w...@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: 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...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X