On-Core Software
August 11, 2020, 05:33:15 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
   Home   Help Search Login Register  
Pages: [1]
Author Topic: change to disallow a session to span beyond 24 hours past entry start time  (Read 4307 times)
Posts: 1

« on: March 12, 2011, 09:45:50 am »

I just upgraded to time master 4.0 and have come to realize this change about disallowing a session to span beyond 24 hours past the entry start time.  Why was this change made?  I typically have long lived tasks, and in previous versions of time master, I could have one time entry and track my daily hours in a session (ie. one session per day). It appears this capability has been removed and I'm curious if their is another way to achieve what I was doing?  Do I have to have a new separate time entry now for every single day?

Thanks -
Hero Member
Posts: 1000

« Reply #1 on: March 12, 2011, 12:29:29 pm »

Yes, we had to make this change as recently more and more people were having critical problems and we had to close this problem from happening.  Sessions are only meant to be for *one* single day and *must* be less than 24 hours of total time.

We had people who were trying to put a weeks worth of days in a single Time Entry and since it was exceeding 24 hours, it would truncate the time to 24 hours, so they would be loosing time for billing.

The second problem is that since they were trying to report *when* they did stuff, the reports only works on the Time Entry date and if they were putting stuff spanning days or weeks in the sessions, they could not figure out why it wouldn't show up on reports.  Say that the user does their billing on a monthly basis.  They had one Time Entry for the last week of a given month, so they bill that out and all is fine.  Then they keep adding to that in the following month and then they try to Report those entries, by date, and get nothing because the reports uses the Time Entry date.

So those are the two issues, that for some reason, were starting to be reported within the past two months.  Despite Sessions being around for over a year, we were getting several emails.  We don't know if people just didn't report having problems until now or new people were just trying to use it differently?!  So that is why we had to force people to use sessions as the only way that they can be used.

In 4.0 we do have one issue that can be confusing and we want to try and come up with a better way of handling this.  When you first create a Time Entry with Sessions, the first thing you need to do is set the Date and Time if you need to "predate" it.  You will notice that you cannot Add sessions until you Save and then either start a timer or go back in and start adding sessions.  The problem lies when you go back in and try to add sessions, but forgot to set the time back.  If the session that you are adding time is less than what you have in the Time Entry, it will not let you enter that time as it precedes the Time Entry Start time.  You would have to go back out to the main Time Entry screen, adjust the time, Save and then go back in.  The extra step of needing to Save is annoying and we are trying to figure out a better way of handling that.  The issue with this is that if you back set the Time in the entry and then added a session.  After saving the sessions it would be possible for you to Cancel out of the Time Entry, instead of Saving, and that would not save the adjusted time and now you would have an overlap in the Time Entry vs. the Session.  So that is why we were forcing you to Save the Time Entry before adding new sessions.

I hope that all makes sense.  Again the problem is that people were not using sessions correctly and it was leading to critical problems.  Please keep in mind that Sessions are for people who either *need* to track their "punch in & out" times, to report to an employer, or people who want to track the "punch in & out" times for their own purposes and may also want to add sessions notes for their own reference (session notes are really not meant to pass on to Clients -- the Reference notes should be used for that).
Pages: [1]
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!