I am trying to create a clock-in and clock-out feature for the staff. The aim is to record clock-in and clock-out dates and times for each staff.
I have created the following action for the clock in and clock out
The issue is every time user clicks the Clock in button; it updates the first row even though the user has already clocked out.
How can I update the second row if the user has already clocked out?
How would users get access to the second row, third row and onwards? You’re showing a details view of the Log tab, which will always default to the first row.
@ThinhDinh My plan was to show a detailed view with clock-in and clock-out buttons.
In detail view, first rows will be the default? Is there any way to access other rows in the detail view?
You can, with a filter, but I don’t think that’s the right way to do it here, since you’re writing to the same table.
Assuming you have a Users table, you can use the Users table and filter it to where “Email is signed-in user” instead. That will make the table tied to the row of the signed-in user.
Then:
YEAR(N)*10000+MONTH(N)*100+DAY(N) with N being the now value. For example it’s 20221220 in my timezone.
In the Logs table, don’t record the employee name, it won’t guarantee to be unique. The record the user’s rowID instead.
In the logs table, create the same “numerical” value for the date, using the “Check in” timestamp in place of the “Now” value.
Create a template column joining the user’s rowID and the numerical value. It would be something like: abcd1234 - 20221220.
Create the same template column in the Users table.
Create a relation from the Users table to the Log table using the template column above, this will let you know if the user has checked in or not today.
Create a lookup on top of that relation and return the “Check out” timestamp. This will let you know if the user has checked out or not today.
The “Check in” button should write a new row to the Logs table, recording the user’s rowID and check in timestamp. It should only be shown when the relation is empty, meaning the user has not checked in today.
The “Check out” button should set the current timestamp through the relation we created, to the “datetime out” column. This makes sure the user writes to the same row they created during the “check in” process. The “Check out” button should only be shown when the relation is not empty AND the lookup check out value is empty.
If you need some inspiration:
ready sample:
See if you like it.
@ThinhDinh Thank you for your response. I really appreciate your help. It took a bit of time to understand it, but finally, it was solved because of your help.
Kind of funny that this comes up since I am currently porting one of my ASP.NET Apps to Glide.
In my App the Employee is actually only registering his own, private PIN on Login and Logout and has no access to the App at all, only admins do.
The App checks his credentials, status (Login/Logout) plus a series of details and presents the admin with a complete list of hours worked, earnings etc…
In the beginning we had a lot of discrepancies but when starting using this simple number pad plus some coding all worked out well.
PS The PINs used by the Employees are stored in their Record and are not to be confused with the PINs issues by Glide to Login.
Have you got the pin access method working in Glide?
@AdamMartin Not yet, need to finalize some other apps before getting back to this one.
This screenshot is from my existing app, not from Gilde:
The Employee has to enter a correct Pin which is verified and if OK the app checks to see if the user is currently logged in or not.
If not, he will be logged in.
If yes, he will be logged out.
This way the Employee does not have to be a User at all.
We started with 2 Buttons (Login + Logout) but many Employees made mistakes which led to double registrations etc…
Thanks for your reply. I am working on a clock in / out app for our business at the moment. Working with user rows in glide - everything works nicely… but as we want to have this running on an iPad as a timeclock terminal I want a simple way for users to validate themselves. Will be going down the pin entry path as well.
I am considering moving away from using the “users” table and simply having an employees table instead. Just need to give consideration to whether there are any security implications.
If the iPad terminal is secured, then there probably isn’t much of a security concern. However, keep in mind that if users are not signing in, then you are not utilizing Row Owners, and ultimately all of that data for all employees is sitting in cache in that device. If someone with enough technical ability has access to snoop the device, they technically could find all information about employees as well as see everyone’s pin code. Just something to be mindful of.
Thanks Jeff… the problem with having users login is simply that it is time consuming and tedious… they will clock in / out for a 15min break… so expecting them to login to push a button to take a break (one example) is not very practical.
What I am thinking is an employee table that utilises a simple pin code… but is related to a user behind the scenes to keep sensitive info “safe”.
Understood. Just making you aware of the security implications if you bypass Glide’s security features. It’s ultimately up to you to make the final decision.
As for data that’s “behind the scenes”, if the table that contains that information is part of the app in any way, shape, or form, it’s still potentially accessible data on essentially an app that is publicly accessible to the world (provided there is a absolutely no form of sign in for the app). You could provide minimal security by at least making it a private app and having an admin user do the initial sign in before the rest of the employees begin to use it with pin codes.
Thanks again Jeff… I was considering that option of an “admin” logging in to the app as you have described.
