tsheetx-developers — Timesheet Next Gen - Developer's mailing list

[Tsheetx-developers] FW: Feedback on branches/txsheet-2.0-demo

[David T. <tom...@us...>]

Mark
I am forwarding to the mailing list, so that others can keep track of what you are saying. On an open-source project like this, try not to write long mails explaining things (especially just to one person). We want to be as transparent as possible. That's why you should think about using the wiki too, mailing list stuff gets lost or forgotten too.
Cheers, and keep up the good work. 


Date: Sun, 14 Nov 2010 15:36:55 +0000
From: ma...@rw...
To: tom...@us...
Subject: Re: [Tsheetx-developers] Feedback on branches/txsheet-2.0-demo


Hi Dave, 

My apologies, what should i rename the branch to?  Templating system doesn't really give a proper description on the full function of my proposed change.

Starting with the key element.  Modrewrite:

The htaccess file contains 3 important lines:

RewriteEngine on

###
#use these lines when on a personal server
#1. if the file exists, then don't process any rules on it
#2. route everything through index.php
###

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule .* index.php/$0 [PT,L]

This essentially forces a single point of entry for every single page in the software.  The point of entry being index.php.  At the moment all that is happening is the page /monthly appears within the template themes/txsheet/template.php

This then allows several features:

1. classes like authenticationManager and common are in the index.php file and form the basis for every page as they are used throughout the site.

2. utilisation of the templateParser class which takes the themes/txsheet/template.php
and css file and loads the requested page i.e. monthly into the {content} part of this template.
 - How else should this be used? - files such as banner.inc, footer.inc and header.inc should be integrated directly into the templateParser stuff which effectively removes any mention of them in monthly.php  The ultimate idea is to reduce the duplication of code throughout the site.

3. the reason why I was using seo friendly links is mainly because it allows for a migration from the old version to the new version without breaking anything or changing the folder structure of the site at the moment.  But we could work out a method to not change the url's instead?

4. other pages can be quickly and easily added into the site.  see the /content folder and the links on the footer of my demo.

Smarty is a similar idea, however this is quite a simple template implementation and would allow a progressive migration without breaking everything whilst the change is made.

Should I start putting all of this on the wiki then?

The forward slash is a temporary "feature" and is caused by the txsheet css line which currently thinks it is relative to the current url so a forward slash makes the css think it is in:

mysite.com/txsheet/monthly/css/myfile.css

The way i've always got around this minor issue is the use of a static variable which works out the path to the 'root' of the site.  I call this Config::getRelativeRoot() which using the url example above would calculate itself to be "/txsheet".  Therefore the txsheet css line could be changed from:

<link href="css/timesheet.css" rel="stylesheet" type="text/css" />

to:

<link href="<?php echo Config::getRelativeRoot();?>/css/timesheet.css" rel="stylesheet" type="text/css" />

I am interested to hear you feedback.  At the moment I am really trying to make changes
in such a way that nothing is broken and the old version and the new version can co-exist
whilst people slowly migrate each page to a more integrated system.

I saw mentions of a total rewrite somewhere but maybe a more progressive rewrite (this as a starting point for example) may be more suitable - thus allowing development of new features such as Peter's approval process whilst page restructuring is also going on.

As a plan what do you think to:

1. move towards a templating style using the system suggested 
2. split the core elements into subfolders to give further structure.
3. cleanup the html errors and start looking at ways to improve the
code structure of the core of the site?

Regards

Mark Wrightson




_____________________________________________
 
Mob:  07725 695178
Email: ma...@rw...
On 14/11/2010 09:06, David Thompson wrote: 


> 
> Hi,
> 
> I have uploaded a new idea into the branches/txsheet-2.0-demo

Super, but can we try to stay consistent with naming: tsheetx is the sourceforge (unix) name. I assume this has nothing to do with the existing 2.0 demo?
 
> Basically this is the start of an attempt to improve the code structure, 
> use more classes,
> integrate a templating system such that code is reused and not copied in 
> several files.

More (and better) use of classes is great, but what do you mean by templating system? I haven't looked at the code yet. Something like smarty?

> The other main point is that you will require the apache mod_rewrite 
> enabled on your webserver. This allows for neater urls such as 
> txsheet/monthly instead of txsheet/monthly.php (as a v simple example)

Not a good idea to enforce this. Most projects I use have this as an option for SEO purposes. That is not a goal for most timesheet users. If you can make it optional, then you will upset less people, and make more friends. 

> Finally once you've logged in, if the url has a / at the end after 
> monthly, the css file won't be correctly found i.e. 
> http://localhost/TimesheetNG/monthly/ and the page won't display 
> correctly. Just remove the trailing slash and everything will be fine.
 
Is that temporary, or a permanent "feature"? Can I point you to the wiki, where you can start documenting your ideas...

> Looking forward to hearing your comments.
> 

Really great work, restructuring code is not easy, and from what you've written, I guess that you have thought about what you are doing. I will try it out as soon as I get a free day....
 
Cheers

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Tsheetx-developers mailing list
Tsh...@li...
https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
 		 	   		  

Re: [Tsheetx-developers] Feedback on branches/txsheet-2.0-demo

[David T. <tom...@us...>]

> 
> Hi,
> 
> I have uploaded a new idea into the branches/txsheet-2.0-demo

Super, but can we try to stay consistent with naming: tsheetx is the sourceforge (unix) name. I assume this has nothing to do with the existing 2.0 demo?
 
> Basically this is the start of an attempt to improve the code structure, 
> use more classes,
> integrate a templating system such that code is reused and not copied in 
> several files.

More (and better) use of classes is great, but what do you mean by templating system? I haven't looked at the code yet. Something like smarty?

> The other main point is that you will require the apache mod_rewrite 
> enabled on your webserver. This allows for neater urls such as 
> txsheet/monthly instead of txsheet/monthly.php (as a v simple example)

Not a good idea to enforce this. Most projects I use have this as an option for SEO purposes. That is not a goal for most timesheet users. If you can make it optional, then you will upset less people, and make more friends. 

> Finally once you've logged in, if the url has a / at the end after 
> monthly, the css file won't be correctly found i.e. 
> http://localhost/TimesheetNG/monthly/ and the page won't display 
> correctly. Just remove the trailing slash and everything will be fine.
 
Is that temporary, or a permanent "feature"? Can I point you to the wiki, where you can start documenting your ideas...

> Looking forward to hearing your comments.
> 

Really great work, restructuring code is not easy, and from what you've written, I guess that you have thought about what you are doing. I will try it out as soon as I get a free day....
 
Cheers 		 	   		  

[Tsheetx-developers] Feedback on branches/txsheet-2.0-demo

[Mark W. <ma...@rw...>]

Hi,

I have uploaded a new idea into the branches/txsheet-2.0-demo

Basically this is the start of an attempt to improve the code structure, 
use more classes,
integrate a templating system such that code is reused and not copied in 
several files.

The only significant changes are that you will need to add your database 
table names
into include/tables.class.php such that they match table_names.inc
I have modified the code to ensure that both the old version and the new 
version still
operate so there are quite a few checks throughout the codebase such as:

if(!class_exists('Site')){}
or
if(!(@$this instanceof templateParser)){}

Once all pages are converted over to the new class based system 
(assuming you approve this idea) the class_exists checks could then be 
removed.

At the moment this is the tidiest way I can think of updating the code 
structure without
completely breaking the rest of the site whilst the changes take place.

The other main point is that you will require the apache mod_rewrite 
enabled on your webserver.  This allows for neater urls such as 
txsheet/monthly instead of txsheet/monthly.php  (as a v simple example)

Finally once you've logged in, if the url has a / at the end after 
monthly, the css file won't be correctly found i.e. 
http://localhost/TimesheetNG/monthly/ and the page won't display 
correctly. Just remove the trailing slash and everything will be fine.

This is an initial conceptual idea and I would appreciate as much 
feedback as possible.

FAO: Peter - in our previous discussion about putting 
client_select_list() and similar into a  class.  I have done exactly 
that (common.class.php).

Looking forward to hearing your comments.

Regards

Mark Wrightson


-- 
_____________________________________________

Mob:  07725 695178
Email: ma...@rw...

Re: [Tsheetx-developers] Getting Involved

[David T. <tom...@us...>]

Hi Mark
 
Sounds like you've approached this from a new angle (what the hell is XHTML compliance?), which is great. We would welcome your contributions.
 
It sounds as if you have done what most of us have started at one point or another, pulled down the (abandoned) code at started improving. The tricky part is delivering the changes back to the "whole". If you are serious about contributing, it is a matter of telling me your sourceforge ID, and we can set-up your SVN commit access.
 
I would suggest putting major changes into a separate branch, so that others can look at them, and then we can gradually merge your changes back into the trunk.
 
How does that sound?
 
Cheers
 
> Date: Mon, 8 Nov 2010 17:50:09 +0000
> From: ma...@rw...
> To: tsh...@li...
> Subject: [Tsheetx-developers] Getting Involved
> 
> Dear Tsheetx-developers
> 
> May I first introduce myself. My name is Mark Wrightson. I am a final 
> year Electronics MEng student from the University of York, UK. Last 
> year i came across your project and proceeded to integrate it into a 
> project management website that I was developing. The version of 
> timesheet was 1.2x or 1.3x. I spent a reasonable amount of time making 
> the application XHTML compliant as well as improving some of the code 
> structure through the removable of global variables, moving towards a 
> more Object Orientated Class Hierarchy.
> 
> I noticed that you have recently released version 1.5x and I would like 
> to be able to contribute some of the enhancements I made to my own 
> version. My first main contribution that I would like to make is making 
> the site XHTML compliant. At a quick glance of: 
> http://demo.timesheetng.org/monthly.php there are 477 errors.
> 
> My question to you is how should I go about making updates and 
> submitting them? I have experience using Subversion (i run subversion 
> at home), however I am unsure about the sourceforge procedures for 
> submitting updates / gaining (earning) write access to the repository.
> 
> I look forward to hearing from you / working with you.
> 
> Regards
> 
> Mark Wrightson
> 
 		 	   		  

[Tsheetx-developers] Getting Involved

[Mark W. <ma...@rw...>]

Dear Tsheetx-developers

May I first introduce myself.  My name is Mark Wrightson.  I am a final 
year Electronics MEng student from the University of York, UK.  Last 
year i came across your project and proceeded to integrate it into a 
project management website that I was developing.  The version of 
timesheet was 1.2x or 1.3x. I spent a reasonable amount of time making 
the application XHTML compliant as well as improving some of the code 
structure through the removable of global variables, moving towards a 
more Object Orientated Class Hierarchy.

I noticed that you have recently released version 1.5x and I would like 
to be able to contribute some of the enhancements I made to my own 
version.  My first main contribution that I would like to make is making 
the site XHTML compliant. At a quick glance of: 
http://demo.timesheetng.org/monthly.php there are 477 errors.

My question to you is how should I go about making updates and 
submitting them?  I have experience using Subversion (i run subversion 
at home), however I am unsure about the sourceforge procedures for 
submitting updates / gaining (earning) write access to the repository.

I look forward to hearing from you / working with you.

Regards

Mark Wrightson

-- 
_____________________________________________

Mob:  07725 695178
Email: ma...@rw...

[Tsheetx-developers] Revision 155 timesheet submission

[Peter L. <pal...@gm...>]

  Hi All,
I have committed some changes to the Zimbra branch revision 155. These 
changes allow a user to submit timesheet records and for a supervisor to 
approve or reject the submissions.

Changed
css/timesheet.css - added two new styles to change character colours 
depending on status
install/timesheet.sql - add a few fields for supervisor and timesheet status
common.inc - add some new functions for drop-down lists. modify function 
split_data_into_discrete_days to correctly record end_stamp
daily.php - add extra column to display task description, plus remove 
row actions if the task has been submitted or approved
report_user - add status field
simple.php, simple_action.php - add copy previous tasks button, and 
disable submitted or approved tasks
task_add_std.php - add standard tasks
timesheet_menu.inc - add standard tasks, supervisor and timesheet submission
user_maint.php, user_action.php - add support for a supervisor, employee 
type, and charge-in rate
weekly.php - changed the colour of times listed to show submitted 
(orange) or approved (green)

New
submit.php - allows a user to submit times for approval
submit_action.php
supervisor.php - allows a supervisor to approve or reject submitted times
supervisor.action.php

Peter

Re: [Tsheetx-developers] copy projects/tasks between users

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

I just realized I checked the code in with the database stuff still
commented out.  So, revision 154 will go through all the motions of actually
copying projects and tasks from one user to another, but not actually make
any database changes.

Admins can un-comment the code in the user_clone.php file to enable the
database changes if they wish.  Next time I check in code, I will try to
remember to un-comment those lines...

-Scott

On Fri, Oct 15, 2010 at 10:47 PM, Scott Miller <sco...@gm...>wrote:

> Hi all,
>
> I just checked in code to allow copying of projects and task assignments
> between users.
> Thanks to Paul Cooper for the original idea of cloning an existing user, I
> took his code and idea and expanded on that to build the new page.
>
> -Scott
>
>

[Tsheetx-developers] copy projects/tasks between users

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

Hi all,

I just checked in code to allow copying of projects and task assignments
between users.
Thanks to Paul Cooper for the original idea of cloning an existing user, I
took his code and idea and expanded on that to build the new page.

-Scott

[Tsheetx-developers] Add standard tasks

[Peter L. <pal...@gm...>]

  Hi All,
I have committed some changes to the Zimbra branch. These changes allow 
the administrator to define standard or common tasks and to add them as 
a selectable list to any project.

The changes are as follows:
New programs
task_add_std.php which is the form to add or modify standard tasks
task_std_action.php which adds standard tasks to a new mysql table 
std_tasks

Modified programs
task_add.php now has an expanded form which includes the standard tasks
task_action.php which processes the selected standard tasks
timesheet_menu.inc to add the standard tasks selection to the menu
install/table_names.inc to include the std_tasks mysql table name
install/timesheet.sql to define the std_tasks mysql table

I have yet to test these changes against the Zimbra branch as a whole. 
Obviously they've been tested on my home machine.

Peter

Re: [Tsheetx-developers] [tsheetx - Open Discussion] RE: Calendars on top

[Jarvis B. <ja...@jn...>]

or perhaps show three calendars so at least the current year is in the 
same place each time. The main fripe I hear about this is that as users 
move from June to July or back again the position of this years calendar 
changes so then end up going from June'10 to July'10 to Aug'11.


SourceForge.net wrote:
> Read and respond to this message at: 
> https://sourceforge.net/projects/tsheetx/forums/forum/779083/topic/3879922
> By: trandill
> 
> My men do not like the two monthly calendars side by side showing two years.
> I have therefore suggested that we keep to only one years calendar by simply
> changing the code in naval_monthly.php from this:

Re: [Tsheetx-developers] [SPAM] Re: Simple time sheet

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

Well, to me, there's nothing inherently wrong or bad with having these two
styles available, and I believe that part of the appeal for this system is
that it can do either style.  But, the way things are currently handled
makes switching between the two styles do things that can surprise the user,
and surprising users is generally a bad thing.

So, Peter, I believe the correct course of action is to attempt to fix the
surprises, not redesign the whole thing; which is what I'm concerned you
maybe thinking.  But, a form that allows for daily entries a week at a time
would probably be welcomed by those that want to track start/stop times.  If
it works well enough, I can see this replacing both the weekly and the daily
views; they would no longer be needed.  But building this new form will not
make any dent whatsoever in the issues we're discussing; and no matter how
well it works, I don't see it replacing the simple form.  But, I could be
persuaded with the right UI design...

As for the configuration table, for a submission/approval system to work, I
see the need to have a table with lots of per user entries that say what
weeks or months have been submitted and which have been approved.  There
have also been many requests to be able to "pre-populate" a new week with a
"default" list of tasks the user picks and a user selectable timezone are
just a few configuration options that could be useful in the future.  But, I
think the approval stuff probably should not be intermixed with user
configuration items; I just didn't think through that when making my "off
the cuff" remark.

-Scott

On Wed, Sep 22, 2010 at 11:56 PM, Peter Lazarus <pal...@gm...> wrote:

>  I agree, Scott that there are problems swapping between the two styles.
> And I can see in the simple form the work that has been done to aggregate
> multiple daily entries into one entry for display and editing.
>
> But precisely because there are issues in running the two styles on the one
> system, I think we need a different approach to make both consistent. Or a
> significant warning of the limitations of the simple time entry.
>
> Yes, in the simple form, the transaction ID field (trans_num in times db)
> can be used to track which time entry is which. I would rather throw the
> problem at the user though. If sometimes the user enters times on the weekly
> sheet and records start and stop time, then, when adjusting hours worked on
> the simple sheet, the user should be presented with the individual entries
> in some format, and he can decide which one to edit. On the other hand, some
> users will complain about that difficulty, and added complexity - it's no
> longer a simple form.
>
> So where my thinking is going at the moment is to leave simple.php as it
> is. I am toying with the idea of the weekly sheet with some simplified entry
> option. It currently displays for each task, the multiple time periods that
> have been worked. Perhaps we could allow these entries to be selected and
> edited. Perhaps a user could elect to enter either hours worked, or start
> and stop times. I need to think this one through a lot more though and draw
> up a mockup on paper.
>
> Submission and approval. Agree that this function needs to be in separate
> forms. Supervisor review, approve function needs to be in a separate form.
> But should the user submission be in a separate form, or another button on
> an existing form? Users may prefer to submit times from the weekly/simple
> sheets just after they have finished editing. But it would be simpler from a
> development point of view to do submission from a separate sheet.
>
> Re the user configuration table. What things are you thinking of putting in
> there?
>
> Peter
>
>
> On 09/23/2010 12:19 AM, Scott Miller wrote:
>
> Well, to be honest, the reason I'm currently advocating never to switch
> between them is because of the various problems that can crop up when doing
> this.  Start/stop times, if they exist, are wiped out to all begin at
> midnight, and week spanning entries can cause time losses or time
> replications.  There may be others, but these issues are currently
> non-trivial to fix, but they are easily avoided if you don't switch between
> the two input methods.
>
> I've thought about how to tackle these issues:  if we keep track of the
> transaction ID's within the simple timesheet, that appears to be a workable
> solution, but then when we throw the aggregation possibilities into the mix,
> things break down. But, iIf we kept a list of the transactions for the
> aggregations, maybe that would work?  If an aggregate is edited, throw out
> the individual entries and create a new one that starts at midnight.  If
> it's not edited, leave them alone.  For entries with a single transaction,
> the length could be edited, leaving the start time in tact.  This also helps
> make the week spanning time entries problems more easily solvable.
>
> As far as submission to management and approval go, I would highly
> recommend putting that stuff in separate forms.
>
> BTW, many things seem to hinge on having some sort of per user
> configuration tables.  Timesheet submission and approval seem to need these
> from what I've been able to figure out.  I would love to have a per user
> timezone entry, but then we need to fix the timezone problems...
>
> -Scott
>
> On Wed, Sep 22, 2010 at 6:05 AM, David Thompson <
> tom...@us...> wrote:
>
>> I would disagree with the view that you shouldn't switch between the two,
>> why not? Sometimes you just want to say I worked today from 7 to 18, and let
>> the TS work out how many hours that was, and other times you say OK,
>> yesterday I did about 4 hours.
>>
>> If the simple timesheet didn't have all the problems that Peter has
>> rightly identified, then it wouldn't be so tricky to swap between the two
>> styles of entry. I could imagine merging the simple and weekly timesheets
>> and offering the user the choice of style.
>>
>> Cheers
>>
>> > From: it...@ea...
>> > To: pal...@gm...; tsh...@li...
>> > Date: Tue, 21 Sep 2010 19:37:05 -0400
>> > Subject: Re: [Tsheetx-developers] Simple time sheet
>>
>> >
>> > I've got to agree with Scott... If you want to enter start and stop
>> times,
>> > use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
>> > timesheet works great for those who only need to enter hours and minutes
>> and
>> > the start/stop times don't mean anything to us: just the time in the end
>> >
>> > -----Original Message-----
>> > From: Peter Lazarus [mailto:pal...@gm...]
>> > Sent: Tuesday, September 21, 2010 7:05 PM
>> > To: tsh...@li...
>> > Subject: [Tsheetx-developers] Simple time sheet
>> >
>> > I posted this comment on simple timesheet entry on the bug tracking
>> > system. Scott Miller has responded and suggested we discuss this issue
>> > on the developers forum. Can the wider community add their opinions and
>> > suggestions. Scott's response is reproduced further down.
>> > Peter
>> >
>> > I've been using the simple timesheet to add a function for submitting
>> and
>> > approving timesheets. The more I work on my new function I discover that
>> > simple timesheet has some inconsistencies with the other entry methods.
>> One
>> > issue that I don't like is that simple deletes the time records and them
>> > puts them back. This means quite a lot of detail can be lost.
>> >
>> > So can we suggest/design a new time entry format, perhaps similar to
>> > simple's approach. Some of the requirements I would like to see are:
>> > - enter times for the week against the projects/tasks
>> > - time entry must include start and stop times to be consistent with the
>> > other input
>> > - multiple periods on the one day against one project/task/description
>> > similar to what can be entered with daily or weekly
>> > - changes to existing times cause db updates rather than
>> > deletion/insertion
>> > - ability to submit time records for a week for approval (requires a
>> > supervisor) although submission could be done in another panel
>> >
>> > (0000231) Scott Miller (developer) - 2010-09-21 20:05
>> > http://bugs.timesheetng.org/view.php?id=109#c231
>> > ----------------------------------------------------------------------
>> > I agree that deleting records only to recreate them seems to be the
>> wrong
>> > thing to do, but keeping track of what items need to change then becomes
>> > necessary and that's not a trivial task.
>> >
>> > I totally disagree with requiring a start and stop time. Simple was
>> > designed for those who don't want to have to deal with start/stop times,
>> > and just want to be able to record time spent per item.
>> >
>> > That said, I believe that if start/stop times exist, they should not be
>> > deleted; again this is not trivial.
>> >
>> > For further discussion, please join the developers mailing list, and
>> lets
>> > discuss this there. You can find a link in the wiki area to join.
>> >
>> > One example of why these are not trivial problems is that simple.php
>> > currently combines multiple time entries for identical task/log
>> messages.
>> > How do you handle an edit of an aggregate amount of time?
>> >
>> > I personally believe that users should be free to choose which system
>> they
>> > want to use, but I highly recommend NEVER switching between time entry
>> > systems because they represent entirely different ways of
>> thinking/looking
>> > at time tracking.
>>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
> _______________________________________________
> Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>

Re: [Tsheetx-developers] [SPAM] Re: Simple time sheet

[Krabina B. <kr...@kd...>]

Dear all,

I think the discussion regarding the relation of simple timesheet and other input methods pretty much relates to my earlyer suggestion: keep the record of work times/absences separate from billing times to projects. Simple timesheet is perfect for doing the latter, so maybe make a simpler version of the weekly and daily input methods just to record precences/absences?

Peter, I'll paste my previous thoughts on this in this e-mail in case you missed my first post.

regards,
Bernhard

> There are two separate goals with time tracking that usually get mixed
> together, which in my opinion is not such a good idea.
> 
> Goal 1 - Track the legally necessary times
> ------------------------------------------
> The requirements are quite basic. You need to record in a timesheet
> the time an employee started to work. Because there are different work
> times, you should be able to track the following:
> - regular work time
> - overtime (maybe overtime 50% and overtime 100%)
> - travel time
> - absences (with reason, e. g. doctor appointment or sickness leave)
> - break (maybe paid and unpaid break)
> - (maybe "block time" - this is a speciality for overtime starting
> after regular work time with more than 3 continuour hours, but this
> could also be left to the HR department ;-)
> 
> In Timesheet NG this could be done be enhancing the idea of the
> absences sheet. It's important to have a report for the employee to
> sign to stat that this were his woking times.
> 
> Goal 2 - Track times associated to projects (or even tasks)
> -----------------------------------------------------------
> What is needed is the number of hours a person records to a certain
> project (per week or month is usually enough). And nice reporting and
> export functions for further controlling purposes.
> 
> The problem now is, that with trying to combine these two goals in one
> solution, you usually have the following effects:
> - tracking becomes inconveniently complex for users, they have to
> track very precicely (9-10, project A, work time, 10-12, project B,
> travel time; 12-14, project B, work time...),
> - tracking solutions tend to become quite complex as well because of
> that
> 
> So my suggestion is to keep these things separated.
> 
> This can cause the problem that the two times recorded might not
> match. There are several possibilities to handle this:
> 1. leave it. If users want to cheat, they will cheat. The
> Presence/Absense sheet is the only legally binding thing. The user has
> to sign it and declare that these have been his/her working times. If
> there are differences on the times recorded for projects and
> presences, they will show up in the controlling.
> 2. make a connection.
> - case a: the user has recorded 40 hours a week and has only assigned
> 30 hours to projects. This case is easy: the tracking tool could
> automatically assign the remaining times to a "project" called
> "administrative tasks" - so everything not billable/productive gets
> added there. (Or the tool does nothing but requiring the user to bill
> exacly 40 hours where the user will manually bill the remaining hours
> to the "project" called "administrative tasks"
> - case b: the user has recorded 40 hours and tries to assign 50 hours
> to projects. Also easy: don't allow it
> 
> For making a connection the use case could be like this:
> - Users track time on a regular basis (dayly is best) to record their
> absence/presence.
> - At the end of a period (usually a week or a month) the user clicks
> on "assign times to projects" or something like this.
> - For the selected period, the number of productive recorded hours (in
> the example 40 for the week) are displayed, the user can assign them
> to predifined projects until he has assigned all hours or there are
> some left that get associated with "adminstrative tasks"
> 
> I know that this approach does not fit to everyone. I can understand
> that one-man-companies want to be able to have everyting recorded in
> big detail, but for companies with employees, time tracking can easily
> be regardes as burdensome and controlling every minute of their
> presence in (and absence from) the company.
> 
> In our company we would vote for a lightwheit solution as I just
> described. And by the way 30 min. intervals are enough, I don't want
> our employees to record "9:12 - 10:22, project A". Assigning times to
> tasks is nice, but in our case not necessary.
> 
> It would be great if Timesheet NG could offer a solution for this
> approach. I think it's actually not very far from it...

----- Ursprüngliche Mail -----
> I agree, Scott that there are problems swapping between the two
> styles. And I can see in the simple form the work that has been done
> to aggregate multiple daily entries into one entry for display and
> editing.
> 
> But precisely because there are issues in running the two styles on
> the one system, I think we need a different approach to make both
> consistent. Or a significant warning of the limitations of the simple
> time entry.
> 
> Yes, in the simple form, the transaction ID field (trans_num in times
> db) can be used to track which time entry is which. I would rather
> throw the problem at the user though. If sometimes the user enters
> times on the weekly sheet and records start and stop time, then, when
> adjusting hours worked on the simple sheet, the user should be
> presented with the individual entries in some format, and he can
> decide which one to edit. On the other hand, some users will complain
> about that difficulty, and added complexity - it's no longer a simple
> form.
> 
> So where my thinking is going at the moment is to leave simple.php as
> it is. I am toying with the idea of the weekly sheet with some
> simplified entry option. It currently displays for each task, the
> multiple time periods that have been worked. Perhaps we could allow
> these entries to be selected and edited. Perhaps a user could elect to
> enter either hours worked, or start and stop times. I need to think
> this one through a lot more though and draw up a mockup on paper.
> 
> Submission and approval. Agree that this function needs to be in
> separate forms. Supervisor review, approve function needs to be in a
> separate form. But should the user submission be in a separate form,
> or another button on an existing form? Users may prefer to submit
> times from the weekly/simple sheets just after they have finished
> editing. But it would be simpler from a development point of view to
> do submission from a separate sheet.
> 
> Re the user configuration table. What things are you thinking of
> putting in there?
> 
> Peter
> 
> On 09/23/2010 12:19 AM, Scott Miller wrote:
> 
> Well, to be honest, the reason I'm currently advocating never to
> switch between them is because of the various problems that can crop
> up when doing this. Start/stop times, if they exist, are wiped out to
> all begin at midnight, and week spanning entries can cause time losses
> or time replications. There may be others, but these issues are
> currently non-trivial to fix, but they are easily avoided if you don't
> switch between the two input methods.
> 
> I've thought about how to tackle these issues: if we keep track of the
> transaction ID's within the simple timesheet, that appears to be a
> workable solution, but then when we throw the aggregation
> possibilities into the mix, things break down. But, iIf we kept a list
> of the transactions for the aggregations, maybe that would work? If an
> aggregate is edited, throw out the individual entries and create a new
> one that starts at midnight. If it's not edited, leave them alone. For
> entries with a single transaction, the length could be edited, leaving
> the start time in tact. This also helps make the week spanning time
> entries problems more easily solvable.
> 
> As far as submission to management and approval go, I would highly
> recommend putting that stuff in separate forms.
> 
> BTW, many things seem to hinge on having some sort of per user
> configuration tables. Timesheet submission and approval seem to need
> these from what I've been able to figure out. I would love to have a
> per user timezone entry, but then we need to fix the timezone
> problems...
> 
> -Scott
> 
> 
> On Wed, Sep 22, 2010 at 6:05 AM, David Thompson <
> tom...@us... > wrote:
> 
> 
> 
> I would disagree with the view that you shouldn't switch between the
> two, why not? Sometimes you just want to say I worked today from 7 to
> 18, and let the TS work out how many hours that was, and other times
> you say OK, yesterday I did about 4 hours.
> 
> If the simple timesheet didn't have all the problems that Peter has
> rightly identified, then it wouldn't be so tricky to swap between the
> two styles of entry. I could imagine merging the simple and weekly
> timesheets and offering the user the choice of style.
> 
> Cheers
> 
> > From: it...@ea...
> > To: pal...@gm... ; tsh...@li...
> > Date: Tue, 21 Sep 2010 19:37:05 -0400
> > Subject: Re: [Tsheetx-developers] Simple time sheet
> 
> 
> >
> > I've got to agree with Scott... If you want to enter start and stop
> > times,
> > use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
> > timesheet works great for those who only need to enter hours and
> > minutes and
> > the start/stop times don't mean anything to us: just the time in the
> > end
> >
> > -----Original Message-----
> > From: Peter Lazarus [mailto: pal...@gm... ]
> > Sent: Tuesday, September 21, 2010 7:05 PM
> > To: tsh...@li...
> > Subject: [Tsheetx-developers] Simple time sheet
> >
> > I posted this comment on simple timesheet entry on the bug tracking
> > system. Scott Miller has responded and suggested we discuss this
> > issue
> > on the developers forum. Can the wider community add their opinions
> > and
> > suggestions. Scott's response is reproduced further down.
> > Peter
> >
> > I've been using the simple timesheet to add a function for
> > submitting and
> > approving timesheets. The more I work on my new function I discover
> > that
> > simple timesheet has some inconsistencies with the other entry
> > methods. One
> > issue that I don't like is that simple deletes the time records and
> > them
> > puts them back. This means quite a lot of detail can be lost.
> >
> > So can we suggest/design a new time entry format, perhaps similar to
> > simple's approach. Some of the requirements I would like to see are:
> > - enter times for the week against the projects/tasks
> > - time entry must include start and stop times to be consistent with
> > the
> > other input
> > - multiple periods on the one day against one
> > project/task/description
> > similar to what can be entered with daily or weekly
> > - changes to existing times cause db updates rather than
> > deletion/insertion
> > - ability to submit time records for a week for approval (requires a
> > supervisor) although submission could be done in another panel
> >
> > (0000231) Scott Miller (developer) - 2010-09-21 20:05
> > http://bugs.timesheetng.org/view.php?id=109#c231
> > ----------------------------------------------------------------------
> > I agree that deleting records only to recreate them seems to be the
> > wrong
> > thing to do, but keeping track of what items need to change then
> > becomes
> > necessary and that's not a trivial task.
> >
> > I totally disagree with requiring a start and stop time. Simple was
> > designed for those who don't want to have to deal with start/stop
> > times,
> > and just want to be able to record time spent per item.
> >
> > That said, I believe that if start/stop times exist, they should not
> > be
> > deleted; again this is not trivial.
> >
> > For further discussion, please join the developers mailing list, and
> > lets
> > discuss this there. You can find a link in the wiki area to join.
> >
> > One example of why these are not trivial problems is that simple.php
> > currently combines multiple time entries for identical task/log
> > messages.
> > How do you handle an edit of an aggregate amount of time?
> >
> > I personally believe that users should be free to choose which
> > system they
> > want to use, but I highly recommend NEVER switching between time
> > entry
> > systems because they represent entirely different ways of
> > thinking/looking
> > at time tracking.
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers

Re: [Tsheetx-developers] Simple time sheet

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

Well, to be honest, the reason I'm currently advocating never to switch
between them is because of the various problems that can crop up when doing
this.  Start/stop times, if they exist, are wiped out to all begin at
midnight, and week spanning entries can cause time losses or time
replications.  There may be others, but these issues are currently
non-trivial to fix, but they are easily avoided if you don't switch between
the two input methods.

I've thought about how to tackle these issues:  if we keep track of the
transaction ID's within the simple timesheet, that appears to be a workable
solution, but then when we throw the aggregation possibilities into the mix,
things break down. But, iIf we kept a list of the transactions for the
aggregations, maybe that would work?  If an aggregate is edited, throw out
the individual entries and create a new one that starts at midnight.  If
it's not edited, leave them alone.  For entries with a single transaction,
the length could be edited, leaving the start time in tact.  This also helps
make the week spanning time entries problems more easily solvable.

As far as submission to management and approval go, I would highly recommend
putting that stuff in separate forms.

BTW, many things seem to hinge on having some sort of per user configuration
tables.  Timesheet submission and approval seem to need these from what I've
been able to figure out.  I would love to have a per user timezone entry,
but then we need to fix the timezone problems...

-Scott

On Wed, Sep 22, 2010 at 6:05 AM, David Thompson <
tom...@us...> wrote:

>  I would disagree with the view that you shouldn't switch between the two,
> why not? Sometimes you just want to say I worked today from 7 to 18, and let
> the TS work out how many hours that was, and other times you say OK,
> yesterday I did about 4 hours.
>
> If the simple timesheet didn't have all the problems that Peter has rightly
> identified, then it wouldn't be so tricky to swap between the two styles of
> entry. I could imagine merging the simple and weekly timesheets and offering
> the user the choice of style.
>
> Cheers
>
> > From: it...@ea...
> > To: pal...@gm...; tsh...@li...
> > Date: Tue, 21 Sep 2010 19:37:05 -0400
> > Subject: Re: [Tsheetx-developers] Simple time sheet
>
> >
> > I've got to agree with Scott... If you want to enter start and stop
> times,
> > use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
> > timesheet works great for those who only need to enter hours and minutes
> and
> > the start/stop times don't mean anything to us: just the time in the end
> >
> > -----Original Message-----
> > From: Peter Lazarus [mailto:pal...@gm...]
> > Sent: Tuesday, September 21, 2010 7:05 PM
> > To: tsh...@li...
> > Subject: [Tsheetx-developers] Simple time sheet
> >
> > I posted this comment on simple timesheet entry on the bug tracking
> > system. Scott Miller has responded and suggested we discuss this issue
> > on the developers forum. Can the wider community add their opinions and
> > suggestions. Scott's response is reproduced further down.
> > Peter
> >
> > I've been using the simple timesheet to add a function for submitting and
> > approving timesheets. The more I work on my new function I discover that
> > simple timesheet has some inconsistencies with the other entry methods.
> One
> > issue that I don't like is that simple deletes the time records and them
> > puts them back. This means quite a lot of detail can be lost.
> >
> > So can we suggest/design a new time entry format, perhaps similar to
> > simple's approach. Some of the requirements I would like to see are:
> > - enter times for the week against the projects/tasks
> > - time entry must include start and stop times to be consistent with the
> > other input
> > - multiple periods on the one day against one project/task/description
> > similar to what can be entered with daily or weekly
> > - changes to existing times cause db updates rather than
> > deletion/insertion
> > - ability to submit time records for a week for approval (requires a
> > supervisor) although submission could be done in another panel
> >
> > (0000231) Scott Miller (developer) - 2010-09-21 20:05
> > http://bugs.timesheetng.org/view.php?id=109#c231
> > ----------------------------------------------------------------------
> > I agree that deleting records only to recreate them seems to be the wrong
> > thing to do, but keeping track of what items need to change then becomes
> > necessary and that's not a trivial task.
> >
> > I totally disagree with requiring a start and stop time. Simple was
> > designed for those who don't want to have to deal with start/stop times,
> > and just want to be able to record time spent per item.
> >
> > That said, I believe that if start/stop times exist, they should not be
> > deleted; again this is not trivial.
> >
> > For further discussion, please join the developers mailing list, and lets
> > discuss this there. You can find a link in the wiki area to join.
> >
> > One example of why these are not trivial problems is that simple.php
> > currently combines multiple time entries for identical task/log messages.
> > How do you handle an edit of an aggregate amount of time?
> >
> > I personally believe that users should be free to choose which system
> they
> > want to use, but I highly recommend NEVER switching between time entry
> > systems because they represent entirely different ways of
> thinking/looking
> > at time tracking.
>

Re: [Tsheetx-developers] Simple time sheet

[David T. <tom...@us...>]

I would disagree with the view that you shouldn't switch between the two, why not? Sometimes you just want to say I worked today from 7 to 18, and let the TS work out how many hours that was, and other times you say OK, yesterday I did about 4 hours.

 

If the simple timesheet didn't have all the problems that Peter has rightly identified, then it wouldn't be so tricky to swap between the two styles of entry. I could imagine merging the simple and weekly timesheets and offering the user the choice of style.

 

Cheers
 
> From: it...@ea...
> To: pal...@gm...; tsh...@li...
> Date: Tue, 21 Sep 2010 19:37:05 -0400
> Subject: Re: [Tsheetx-developers] Simple time sheet
> 
> I've got to agree with Scott... If you want to enter start and stop times,
> use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
> timesheet works great for those who only need to enter hours and minutes and
> the start/stop times don't mean anything to us: just the time in the end
> 
> -----Original Message-----
> From: Peter Lazarus [mailto:pal...@gm...] 
> Sent: Tuesday, September 21, 2010 7:05 PM
> To: tsh...@li...
> Subject: [Tsheetx-developers] Simple time sheet
> 
> I posted this comment on simple timesheet entry on the bug tracking 
> system. Scott Miller has responded and suggested we discuss this issue 
> on the developers forum. Can the wider community add their opinions and 
> suggestions. Scott's response is reproduced further down.
> Peter
> 
> I've been using the simple timesheet to add a function for submitting and
> approving timesheets. The more I work on my new function I discover that
> simple timesheet has some inconsistencies with the other entry methods. One
> issue that I don't like is that simple deletes the time records and them
> puts them back. This means quite a lot of detail can be lost.
> 
> So can we suggest/design a new time entry format, perhaps similar to
> simple's approach. Some of the requirements I would like to see are:
> - enter times for the week against the projects/tasks
> - time entry must include start and stop times to be consistent with the
> other input
> - multiple periods on the one day against one project/task/description
> similar to what can be entered with daily or weekly
> - changes to existing times cause db updates rather than
> deletion/insertion
> - ability to submit time records for a week for approval (requires a
> supervisor) although submission could be done in another panel
> 
> (0000231) Scott Miller (developer) - 2010-09-21 20:05
> http://bugs.timesheetng.org/view.php?id=109#c231
> ----------------------------------------------------------------------
> I agree that deleting records only to recreate them seems to be the wrong
> thing to do, but keeping track of what items need to change then becomes
> necessary and that's not a trivial task.
> 
> I totally disagree with requiring a start and stop time. Simple was
> designed for those who don't want to have to deal with start/stop times,
> and just want to be able to record time spent per item.
> 
> That said, I believe that if start/stop times exist, they should not be
> deleted; again this is not trivial.
> 
> For further discussion, please join the developers mailing list, and lets
> discuss this there. You can find a link in the wiki area to join.
> 
> One example of why these are not trivial problems is that simple.php
> currently combines multiple time entries for identical task/log messages.
> How do you handle an edit of an aggregate amount of time?
> 
> I personally believe that users should be free to choose which system they
> want to use, but I highly recommend NEVER switching between time entry
> systems because they represent entirely different ways of thinking/looking
> at time tracking.
> 
> 
> 
> I've been using the simple timesheet to add a function for submitting and
> approving timesheets. The more I work on my new function I discover that
> simple timesheet has some inconsistencies with the other entry methods. One
> issue that I don't like is that simple deletes the time records and them
> puts them back. This means quite a lot of detail can be lost.
> 
> So can we suggest/design a new time entry format, perhaps similar to
> simple's approach. Some of the requirements I would like to see are:
> - enter times for the week against the projects/tasks
> - time entry must include start and stop times to be consistent with the
> other input
> - multiple periods on the one day against one project/task/description
> similar to what can be entered with daily or weekly
> - changes to existing times cause db updates rather than
> deletion/insertion
> - ability to submit time records for a week for approval (requires a
> supervisor) although submission could be done in another panel
> 
> 
> Scott Miller's reply posted on bug tracking system:
> 
> (0000231) Scott Miller (developer) - 2010-09-21 20:05
> http://bugs.timesheetng.org/view.php?id=109#c231
> ----------------------------------------------------------------------
> I agree that deleting records only to recreate them seems to be the wrong
> thing to do, but keeping track of what items need to change then becomes
> necessary and that's not a trivial task.
> 
> I totally disagree with requiring a start and stop time. Simple was
> designed for those who don't want to have to deal with start/stop times,
> and just want to be able to record time spent per item.
> 
> That said, I believe that if start/stop times exist, they should not be
> deleted; again this is not trivial.
> 
> For further discussion, please join the developers mailing list, and lets
> discuss this there. You can find a link in the wiki area to join.
> 
> One example of why these are not trivial problems is that simple.php
> currently combines multiple time entries for identical task/log messages.
> How do you handle an edit of an aggregate amount of time?
> 
> I personally believe that users should be free to choose which system they
> want to use, but I highly recommend NEVER switching between time entry
> systems because they represent entirely different ways of thinking/looking
> at time tracking.
> 
 		 	   		  

Re: [Tsheetx-developers] Simple time sheet

[EAS L. IT D. <it...@ea...>]

I've got to agree with Scott... If you want to enter start and stop times,
use the Stopwatch, Daily Timesheet, or Weekly Timesheet. The Simple
timesheet works great for those who only need to enter hours and minutes and
the start/stop times don't mean anything to us: just the time in the end

-----Original Message-----
From: Peter Lazarus [mailto:pal...@gm...] 
Sent: Tuesday, September 21, 2010 7:05 PM
To: tsh...@li...
Subject: [Tsheetx-developers] Simple time sheet

I posted this comment on simple timesheet entry on the bug tracking 
system. Scott Miller has responded and suggested we discuss this issue 
on the developers forum. Can the wider community add their opinions and 
suggestions. Scott's response is reproduced further down.
Peter

I've been using the simple timesheet to add a function for submitting and
approving timesheets. The more I work on my new function I discover that
simple timesheet has some inconsistencies with the other entry methods. One
issue that I don't like is that simple deletes the time records and them
puts them back. This means quite a lot of detail can be lost.

So can we suggest/design a new time entry format, perhaps similar to
simple's approach. Some of the requirements I would like to see are:
- enter times for the week against the projects/tasks
- time entry must include start and stop times to be consistent with the
other input
- multiple periods on the one day against one project/task/description
similar to what can be entered with daily or weekly
- changes to existing times cause db updates rather than
deletion/insertion
- ability to submit time records for a week for approval (requires a
supervisor) although submission could be done in another panel

  (0000231) Scott Miller (developer) - 2010-09-21 20:05
  http://bugs.timesheetng.org/view.php?id=109#c231
----------------------------------------------------------------------
I agree that deleting records only to recreate them seems to be the wrong
thing to do, but keeping track of what items need to change then becomes
necessary and that's not a trivial task.

I totally disagree with requiring a start and stop time.  Simple was
designed for those who don't want to have to deal with start/stop times,
and just want to be able to record time spent per item.

That said, I believe that if start/stop times exist, they should not be
deleted; again this is not trivial.

For further discussion, please join the developers mailing list, and lets
discuss this there.  You can find a link in the wiki area to join.

One example of why these are not trivial problems is that simple.php
currently combines multiple time entries for identical task/log messages.
How do you handle an edit of an aggregate amount of time?

I personally believe that users should be free to choose which system they
want to use, but I highly recommend NEVER switching between time entry
systems because they represent entirely different ways of thinking/looking
at time tracking.



I've been using the simple timesheet to add a function for submitting and
approving timesheets. The more I work on my new function I discover that
simple timesheet has some inconsistencies with the other entry methods. One
issue that I don't like is that simple deletes the time records and them
puts them back. This means quite a lot of detail can be lost.

So can we suggest/design a new time entry format, perhaps similar to
simple's approach. Some of the requirements I would like to see are:
- enter times for the week against the projects/tasks
- time entry must include start and stop times to be consistent with the
other input
- multiple periods on the one day against one project/task/description
similar to what can be entered with daily or weekly
- changes to existing times cause db updates rather than
deletion/insertion
- ability to submit time records for a week for approval (requires a
supervisor) although submission could be done in another panel


Scott Miller's reply posted on bug tracking system:

  (0000231) Scott Miller (developer) - 2010-09-21 20:05
  http://bugs.timesheetng.org/view.php?id=109#c231
----------------------------------------------------------------------
I agree that deleting records only to recreate them seems to be the wrong
thing to do, but keeping track of what items need to change then becomes
necessary and that's not a trivial task.

I totally disagree with requiring a start and stop time.  Simple was
designed for those who don't want to have to deal with start/stop times,
and just want to be able to record time spent per item.

That said, I believe that if start/stop times exist, they should not be
deleted; again this is not trivial.

For further discussion, please join the developers mailing list, and lets
discuss this there.  You can find a link in the wiki area to join.

One example of why these are not trivial problems is that simple.php
currently combines multiple time entries for identical task/log messages.
How do you handle an edit of an aggregate amount of time?

I personally believe that users should be free to choose which system they
want to use, but I highly recommend NEVER switching between time entry
systems because they represent entirely different ways of thinking/looking
at time tracking.




----------------------------------------------------------------------------
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Tsheetx-developers mailing list
Tsh...@li...
https://lists.sourceforge.net/lists/listinfo/tsheetx-developers

[Tsheetx-developers] Thanks to all for help with "missing hours"... here is the solution:

[Zach S. <zs...@ea...>]

My sincere THANK YOU to everyone who helped with this today, especially to
Scott who spent the better part of the day working on this with me. 

 

As it turns out, the data was not "technically" missing, but it was Null (I
told yall I wasn't crazy and that it was gone!). During the upgrade from 1.4
to 1.5.2, there is the creation of the "Duration" field in the times table.
This "Duration" is calculated in minutes the first time that data is called
or viewed in the new version. 

 

The problem we (and by we I mean I): We had the locale in the tsng
configuration set to US/Eastern, however the localhost locale is
US/Mountain. Because we use the simple timesheet, which automatically
assumes and calculates the times starting from midnight, I already had a 2
hour delay. Looking at the weekly timesheet, Scott noticed that we somehow
had a bunch of negative hours logged (because of the 2 hour time difference
in localhost time TS locale time). The negative hours were greater (or less
than I guess. or however you best say that :-) ) then the positive hours.

 

To resolve this, we set the locale in the tsng configuration file to my
localhost timezone (US/Mountain) BEFORE ~BEFORE~ viewing any of the data
after doing another install/upgrade to 1.5.2

 

It was also discovered today that 1.5.2 will operate on a system with less
than php5 on it, by removing a variable symbol from one of the files, and
adding a character to the unique ID function (if you try installing on less
than php5, it will give you the errors and line numbers to go find. very
simple for me to figure out)

 

Also, I am using the SHA1 option with no issues or errors. I hear that is a
rare occurance?

 

I cannot express my thanks to everyone again for this. at the end of the
day, all works well, all problems figured out, and I had a lot of time to
begin finding ways I can screw up the new version playing the reports :-)

 

Thanks everyone

 

-hakatak 

 

 

 

 

  _____  

This message is for the designated recipient(s) only and may contain
privileged or confidential information. If you are not the intended
recipient, please advise the sender immediately by reply email and delete
this message and any attachments without retaining a copy. No representation
is made that this email or any attachments are free of viruses.

 

 

Re: [Tsheetx-developers] Fwd: TimeSheet NG

[David T. <tom...@us...>]

Most issues in Mantis (http://busg.timesheetng.org) are new feature requests, take a look at these to see what other people want.

 

We've got plenty of ideas, but so little time...


 

---------- Forwarded message ----------
From: Scott Miller <sco...@gm...>
Date: Thu, Sep 16, 2010 at 3:51 PM
Subject: Re: [Tsheetx-developers] TimeSheet NG
To: James Vassie <Jam...@re...>


Hi James,

Welcome.  To start, I'd recommend reading some of the recent archived messages and the forum area, there have been a number of ideas thrown out within the past month or so.

One "hot" area to me, that I've implemented but it probably won't make it as-is into the official version was the idea of having task "types" so certain kinds of reports were easier to write.  The best idea so far seems to be to have the idea of tasks being able to be part of multiple "types" kinda like users can be part of multiple groups in linux.  I'm not sure how to go about implementing that so that it's relatively efficient...

-Scott






On Thu, Sep 16, 2010 at 3:03 PM, James Vassie <Jam...@re...> wrote:







Hi Guys/Gals,
 
Was speaking to a friend earlier today, and he mentioned TimeSheet NG to me, I had been thinking of/planning a similar project, but thought I’d take a look, and I must say you guys have done a fab job with this! Will be using this to keep track of my projects now, very useful indeed!
 
I would also be quite interested in helping out with things if you need it; I had a read of the ‘Get Involved’ page, and the Wiki, wondering what sort of ideas people had had regarding its expansion and development? I’d be more than willing to help out and contribute.
 
Many Thanks
James 		 	   		  

[Tsheetx-developers] report updates checked into SVN

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

Hi all,

I checked in the improvements to the reports I talked about in previous
email messages a little bit ago.
No immanent plans to create a new release though...

-Scott

[Tsheetx-developers] Fwd: TimeSheet NG

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

oops, I didn't mean to just reply directly to him...

---------- Forwarded message ----------
From: Scott Miller <sco...@gm...>
Date: Thu, Sep 16, 2010 at 3:51 PM
Subject: Re: [Tsheetx-developers] TimeSheet NG
To: James Vassie <Jam...@re...>


Hi James,

Welcome.  To start, I'd recommend reading some of the recent archived
messages and the forum area, there have been a number of ideas thrown out
within the past month or so.

One "hot" area to me, that I've implemented but it probably won't make it
as-is into the official version was the idea of having task "types" so
certain kinds of reports were easier to write.  The best idea so far seems
to be to have the idea of tasks being able to be part of multiple "types"
kinda like users can be part of multiple groups in linux.  I'm not sure how
to go about implementing that so that it's relatively efficient...

-Scott


On Thu, Sep 16, 2010 at 3:03 PM, James Vassie <Jam...@re...>wrote:

>  Hi Guys/Gals,
>
>
>
> Was speaking to a friend earlier today, and he mentioned TimeSheet NG to
> me, I had been thinking of/planning a similar project, but thought I’d take
> a look, and I must say you guys have done a fab job with this! Will be using
> this to keep track of my projects now, very useful indeed!
>
>
>
> I would also be quite interested in helping out with things if you need it;
> I had a read of the ‘Get Involved’ page, and the Wiki, wondering what sort
> of ideas people had had regarding its expansion and development? I’d be more
> than willing to help out and contribute.
>
>
>
> Many Thanks
>
> James
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>

[Tsheetx-developers] TimeSheet NG

[James V. <Jam...@re...>]

Hi Guys/Gals,

 

Was speaking to a friend earlier today, and he mentioned TimeSheet NG to
me, I had been thinking of/planning a similar project, but thought I'd
take a look, and I must say you guys have done a fab job with this! Will
be using this to keep track of my projects now, very useful indeed!

 

I would also be quite interested in helping out with things if you need
it; I had a read of the 'Get Involved' page, and the Wiki, wondering
what sort of ideas people had had regarding its expansion and
development? I'd be more than willing to help out and contribute.

 

Many Thanks

James

Re: [Tsheetx-developers] [tsheetx - Help] Saving wrong time

[David T. <tom...@us...>]

I checked the proposed changes into SVN already.
 
> Date: Thu, 16 Sep 2010 09:18:24 +0100
> From: ja...@jn...
> To: tsh...@li...
> Subject: Re: [Tsheetx-developers] [tsheetx - Help] Saving wrong time
> 
> Not a solution but for what it's worth I found the timezone settings in 
> tsheetx to be tempermental. The only way I found to make the system 
> stable was to explicitly set the timezone in php.ini to 'Europe/London'. 
> Which I know is what you said you can't do but does illustrate that 
> something doesn't appear to be totally in that bit of the system.
> 
> SourceForge.net wrote:
> > Read and respond to this message at: 
> > https://sourceforge.net/projects/tsheetx/forums/forum/779084/topic/3853494
> > By: jurisprogram
> >
> > If I use the simple timesheet page and enter say 5 hours for 9/15 and save,
> > it splits it up to 4 hours on Tuesday and 1 hour on Wednesday. A similar thing
> > happens for other days I've tried.
> >
> > Could this be a time zone issue? My box is using UTC, and I set the timezone
> > to America/New_York on the config page. If so I'm not allowed to change the
> > timezone on the box.
> >
 		 	   		  

Re: [Tsheetx-developers] [tsheetx - Help] Saving wrong time

[Jarvis <ja...@jn...>]

Not a solution but for what it's worth I found the timezone settings in 
tsheetx to be tempermental. The only way I found to make the system 
stable was to explicitly set the timezone in php.ini to 'Europe/London'. 
Which I know is what you said you can't do but does illustrate that 
something doesn't appear to be totally in that bit of the system.

SourceForge.net wrote:
> Read and respond to this message at: 
> https://sourceforge.net/projects/tsheetx/forums/forum/779084/topic/3853494
> By: jurisprogram
>
> If I use the simple timesheet page and enter say 5 hours for 9/15 and save,
> it splits it up to 4 hours on Tuesday and 1 hour on Wednesday.  A similar thing
> happens for other days I've tried.
>
> Could this be a time zone issue?  My box is using UTC, and I set the timezone
> to America/New_York on the config page.  If so I'm not allowed to change the
> timezone on the box.
>
> _____________________________________________________________________________________
> You are receiving this email because you elected to monitor this topic or entire forum.
> To stop monitoring this topic visit: 
> https://sourceforge.net/projects/tsheetx/forums/forum/779084/topic/3853494/unmonitor
> To stop monitoring this forum visit: 
> https://sourceforge.net/projects/tsheetx/forums/forum/779084/unmonitor
>
>   

Re: [Tsheetx-developers] Export to Excel not working in IE?

[Scott M. <Sco...@pr...>]

Argggh I hate MS...

 

I was bitten by other issues with IE on reports that I'd modified
locally.  So, after working on it for 5 hours, I've finally fixed my
issues, and the IE not loading an excel file problem.

 

There are MANY things that needed to be fixed.  The excel "headers" need
to appear before the session_start call, and some of the headers caused
IE to not be able to download the file.  My issues were caused by IE not
handling "buttons" correctly, and thus I had to mess with code to fix
that up.

 

So, I've now got export to excel working for IE again, and I'll be
checking in some nice "buttons" for exporting to excel and for printing.

 

Watch for those improvements by the end of the week (I hope).

 

-Scott

 

________________________________

From: Scott Miller [mailto:Sco...@pr...] 
Sent: Monday, September 13, 2010 12:37 PM
To: David Thompson
Cc: tsh...@li...
Subject: Re: [Tsheetx-developers] Export to Excel not working in IE?

 

Tested on a co-worker's machine this morning, they had the same problem
with IE that I have when attempting to export to excel...

 

I've attached an image that shows the error I'm getting.

 

-Scott

 

 

________________________________

From: Scott Miller [mailto:sco...@gm...] 
Sent: Sunday, September 12, 2010 8:31 PM
To: David Thompson
Cc: tsh...@li...
Subject: Re: [Tsheetx-developers] Export to Excel not working in IE?

 

Oh, forgot about the rest of your message.  The nice thing about going
to Excel is we pretty much don't need to do anything special to get it
to work.  Output to CVS, I think, would require us to rewrite how each
form is created in two different ways.  That's going to be brittle.

On Sun, Sep 12, 2010 at 8:28 PM, Scott Miller <sco...@gm...>
wrote:

Hmmm, from memory, I was getting an error something along the lines of
"Can't find remote file" when using IE 8, firefox works just fine.  But
it is certainly possible there's something wrong with my machine, I
haven't tested with anyone else's machine yet...

-Scott

On Sun, Sep 12, 2010 at 7:54 AM, David Thompson
<tom...@us...> wrote:

	Aside from solving the immediate problem (though a quick test
with XP/IE/Excel2003 worked for me), we should maybe long term go for a
neutral solution, e.g. just export a CSV file.
	Most finance programs can handle CSV files, can't they?
	Cheers
	 

	
________________________________


	Date: Fri, 10 Sep 2010 15:06:49 +0000
	From: sco...@gm...
	To: tsh...@li...
	Subject: [Tsheetx-developers] Export to Excel not working in IE?

	
	
	It could just be a bad memory on my part, but I thought at one
time the export to excel function worked in both Firefox and IE.
	
	I am working on a few minor improvements to the existing
reports, and have noticed that the export function fails in IE now.  It
tries, but immediately fails.  
	
	So, am I forgetting that this never worked, or has Microsoft
managed to break this for us in one of their IE updates?  If it's
Microsoft's fault, anyone know how to fix it?
	
	-Scott

	 

	
------------------------------------------------------------------------
------
	Start uncovering the many advantages of virtual appliances
	and start using them to simplify application deployment and
	accelerate your shift to cloud computing
	http://p.sf.net/sfu/novell-sfdev2dev
	
	_______________________________________________
	Tsheetx-developers mailing list
	Tsh...@li...
	https://lists.sourceforge.net/lists/listinfo/tsheetx-developers

 

 

Re: [Tsheetx-developers] Looking to make a required field for Timesheet NextGen

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

Hey Zack,

To do this, you'll need to make changes to the simple and daily timesheet
files and check that the description field is filled out using java script
before the form is submitted.  There's already some code that does some
checks in javascript in the simple.php file, so look there to get started.

-Scott

On Mon, Sep 13, 2010 at 9:19 PM, EAS LeadGen IT Dept <it...@ea...>wrote:

>  Hello! Scott said this is possible and to check here for guidance.
>
>
>
> I am wanting to make the description field mandatory, but only if the task
> is “Reports/Research/Data” regardless of Client or Project. Does anyone have
> an idea how to do this and where the code would need to be placed?
>
>
>
> Thank you all so much
>
>
>
> -Zach Smith
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>

[Tsheetx-developers] Looking to make a required field for Timesheet NextGen

[EAS L. IT D. <it...@ea...>]

Hello! Scott said this is possible and to check here for guidance. 

 

I am wanting to make the description field mandatory, but only if the task
is "Reports/Research/Data" regardless of Client or Project. Does anyone have
an idea how to do this and where the code would need to be placed?

 

Thank you all so much

 

-Zach Smith