[Asterisk-Dev] Open source time card application for Asterisk

[Steven Critchfield]

On Tue, 2005-09-27 at 10:26 -0500, Tilghman Lesher wrote:
> On Tuesday 27 September 2005 08:27, Steven wrote:
> > Small problem, this gives you no ability to log a clock out if you
> > missed the clock in.
> 
> I'd consider that a feature.  Most timeclocks don't.

The few I have dealt with, all from the user side, basically started
with some state and toggled it with a event recording. It was very
possible to claim the card reader didn't work and get into a position
where your clock in didn't work. Granted not likely a case here unless
you claim crappy phone lines kept you from using DTMF. So this broken
state would then allow one to clock in when you where meaning to clock
out. The fix was for a duly authorized person to make the simulated
clock in event that changed your clock in event to the clock out event. 

> > Also I don't know enough about the ODBC functions, but does it give
> > you any feedback on failure?
> 
> No, it doesn't.

That would be a problem. Say for instance the DB didn't accept the clock
in event for any reason including not accepting connections, now you
where not notified of the error and upon clock out, you do not have a
record to match with to do a clock out and no error message again to let
you know of the problem. One error compounds to 2 without user
notification.

I'll grant what you threw out here was meant more as an example. I don't
want someone to think it is ready for real usage.

> > On suggestion to act more like a time clock would be to merge them
> > together into one function that just recorded a clock event. Then you
> > use knowledge about the time and ordering of events to determine if
> > it is a clock in or clock out event.
> 
> That's certainly another way to do it.  I prefer to have events matched.

I would enjoy it as well, but you see my complaint above.

> > If the two are merged, and a clock in event failed or, more likely,
> > missed by the user, a clock out event can still be processed and
> > later corrected by inserting a value that the administrator is
> > willing to accept as a clock in event.
> 
> In other words, the record is fudged.  If that's the case, the admin
> can certainly fudge the entire record just as easily.

Fudging the entire record is possible, but it would be nice to have
events that are known and done by the user instead of an admin if
possible. I'm suggesting only one fudged event, not 2 fudged events. 

Also with proper error messaging, you are able to have the affected user
bring the problem to the admin and have it fixed before it becomes too
much of a problem. 

In the case I point out at the beginning, missing a clock in event with
proper user error messages, allows one to notify the admin near or
before the clock in event is critical with respect to attendance policy.
If you can advise the admin of the error before any late attendance
policy would kick in, you can then avoid the question of if it is being
used as a method to bypass attendance policy. This is similar to the
problem some chronically late personnel tried to exploit by claiming to
misplace their badge and therefore couldn't clock in. If they couldn't
inform a duly authorized person of their presence before the time they
would be tardy, they would incur the tardy penalty. 

I offer these up as they become considerations as you need to weed out
technical problems and solutions from the crafty ways people try to
circumvent policy.
-- 
Steven Critchfield <critch at basesys.com>