Row actions to create logbook entries (clock in and clock out)

We have a job detail page built which has a table listing the users associated with the job thru a junction object job_users.  In the list of users we want to add a row action which will clock the user in and one for out.  To “clock in” the row action sequence need to add a new log entry to the log entry with the following fields:
type = time
created by = logged in user (log entry object)
user = the user listed in the row  (log entry object)
time in = current date/time  (log entry object)
job = the job you are on the detail page of  (log entry object)
user status = true (for clock in)  (user object)
save and update the row

for clock out
find the last log entry for the current job that had a clock in time and a blank clock out time for that user and job
update that log entry setting the time out field to the current time.
set user status to false
save and update the row.

Can you help me thru this?  How do I get the data from the current row and job to feed these fields?

So here are some ideas for creating buttons that do what you are asking. 

Creating new log entry:  Use the “create new row” action to add a row to a “Logbook” model.  Make sure you have at least Skuid V5.13 installed, because there is a feature that is critical there.  You will find an extra icon is exposed when you select this type that lets you  “add default”   Here you can set all the required items.  
- User will come from the UserJob model row in context,  
- Job could come from there too,  or from a global merge variables  {{$}}  
- The “today” date literal will pass current time into a date time field.
 Once those are complete,  use the save model action to finish.  (and maybe requery models to get ready for step two below). 

Closing a log entry:  I think you need to create a new model that pulls in “open log” entries.  It should not load data on page load,  it should have conditions on Job and status = clocked in that are always on.  It should also have a condition on user that is blank and filterable default off.  

The row action button needs to do the following things:
- Activate the user condition and pass the user identified in the row.
- Query the OpenLogEntries model
- Update field on model to change the status value to false and maybe add a time out value
- Then save the model, and requery things to make sure everything is in synch on your page. 

One bummer in this scenario is that you can’t easily conditionally render the two buttons. The table is on the UserJob model,  and the data you need is in a logbook or “openlog” model. Row actions can only be conditionally rendered on their current model, So you don’t have easy access to data that could be used to show the right button.   But maybe you could create a formula field on the UserJob object to bring in latest logbook status value and then condionally render on that.  (Where there is a will there is a way…)

Hopefully that sketch isn’t too simplistic.  Let us know if you need further clarification. 

So I have it working and great thanks for that.  Here the issue, I created a model for "clocked_in_logs which finds an open log entry with the row’s user and job name.  The clock out action updates the clock out time, perfect.  Now if I clock that person out again, there should be no open logs.  I want that to sow a message but the action runs as if it worked.  It did not update any fields which is good, but it should instead say “you are not clocked in”

I did grant access to skuid, this is on the team tab of the Jobdetail page.

I think the more useful solution would be to conditionally render the “close log” button.  This would eleminate the chance that a user could try to log out if they were not already logged in.  

Though it is slightly complicated as I explain above,  it is feasible using declarative tools, while checking to see if a record is returned by the model query  and only moving forward if that is successful is only possible in Javascript right now.  

This would be a perfect use case for “action conditions”  wich is a feature request a few customers have been asking for.  We’re considering it, but worried about the complexity. 

Stay tuned. 

Ah, great minds.  I did that very thing and it seems to be working very well.  Thanks for all the help.

No worries, glad we could help!