Page 1 of 1
Best way to create a clock-in-clock out page control
Posted: Tue Aug 01, 2006 11:34 am
by hydroxide
I have the task of creating a page for the intranet that will allow employees to clock in when they get to work, and clock out when they leave, from the web. Now, here is the issue: I'm not sure what the best way to go about determining whether or not they are clocked in or out, and what to show accordingly. My original idea was to have a page in which, if the employee was not clocked for that day, it would show the appropriate dialog for them to clock in, and then when they were ready to log out, the revisit the page, and the log out dialog shows up. Herein lies the problem. I don't want to use cookies or anything like that, so I was trying to figure out a way to check to see if there had been a clock in or clock out record entered in the database from the most recent record for that user by querying the DB and foreaching over the result. However, I'm not sure if this will work. If anyone has any ideas as to how I could better control what is displayed on the page (in accordance with whether or not they've clocked for the day or not) it would be much appreciated. I'm not looking for hand-holding... more just a general idea of how to go about doing it.
This is kinda what I started doing with it... (it's kind of a lot)
http://hashphp.org/pastebin?pid=7871
EDIT: I do have a user log in/log out system set up. I'm just now looking for a way to control the above.
Posted: Tue Aug 01, 2006 11:39 am
by RobertGonzalez
Each user should only have access to their information, otherwise Johnny Screwball could potentially clock me out (or vice-versa). You are going to need to be able to set this up based on a logged user system of some sort. The nice thing is that if the user has to long in to see their times, then you can capture their presence at that time. The hard part would be enforcing clock-outs and such.
Posted: Tue Aug 01, 2006 11:42 am
by hydroxide
Everah wrote:Each user should only have access to their information, otherwise Johnny Screwball could potentially clock me out (or vice-versa). You are going to need to be able to set this up based on a logged user system of some sort. The nice thing is that if the user has to long in to see their times, then you can capture their presence at that time. The hard part would be enforcing clock-outs and such.
I have a user log-in system in place. They need to be able to type in their times (not based on when they log in), because what if they get help up helping someone at the receptionist's desk when they come in, and can't immediately clock in?
Posted: Tue Aug 01, 2006 12:00 pm
by GM
I assume that in the end, your HR guys are going to want some kind of reports out of this thing, so I'd opt for maximum flexibility here from the beginning, because - speaking from experience - once they start dreaming up reports, they'll also start dreaming up other things they'd like to see on their reports like... "What percentage of worker A's time is spent doing X?", which then makes your simple intranet page turn into an activity tracking application.
Some things to think about:
- What if a user forgets to clock out? You'll need some sort of default cut-off time otherwise you'll run into the next day.
- Do you have to deal with a night-shift? This could cause problems because you wouldn't be able to count a "day" as a discrete unit of time in which a user can be clocked in exactly once.
- Same about split shifts - is it possible that a user will need to clock in/out more than once a day?
- Who eventually will need visibility of the database contents?
- Will the user be able to retrospectively change things? (maybe they were off site or not at a computer)
- Will someone have superuser rights in order to retroactively insert/change records?
You can check if a user is logged in by testing the most recent record for a null "clock out" timestamp - if the timestamp is null, the user is clocked in. As to table layouts, it really depends on how complex you think the specification could get - you could opt for a simple 1 worker - 1 day - 1 clock in - 1 clock out table in the simplest case, with the primary key being id_worker, clock_date. Or, in a more complex case you could have id_worker - id_activity - activity_start - activity_end, where to begin with the only activity is "work".
This might allow for extra flexibility in the long run, but would be overkill if this was simply not required.
On the face of it, it doesn't sound too difficult, but these things have a habit of growing into monsters. If you set out with a good design from the beginning, you'll have less problems.
One thing I've always found helps: Never trust the specification, and never rely on being able to point to it when they ask for changes.