Employee signin/out

[AndyPowerAppNew]

• have a list called 'StaffWhosin' the 'employee' name is a lookup list from 'StaffNames' i can get a signin date time etc, but the signout againist the name, doesnt work, can you help again.

basixally on the sign out , I would like a dropdown which it gets from the ‘staffwhosin’ list of staff that have already signed in - then pick the name from the dropdown on the ‘sign out’ screen , they would then press ‘sign out’ button , function would then find the record in the ‘staffwhosin’ then put a date and time in the ‘sign out’ column next to the name selected from the dropdown.

can anyone help plesse with code 

[AndyPowerAppNew]

Thank you, i have loaded this , but i think there are some errors - i will try and get this working, and add other stuff like employee dropdown of names etc. meanwhile i tries to get somewhere, with signout, here is my code, how can i allow multiple entries it the list, it seems to only have 1 on the list, if i have one that one entry, the checkout will not show;

what is the reson for this, is my code not right, can we fix this?

Thanks

[AndyPowerAppNew]

Also @poweractivate ,  doesnt need to keep hortical data just the data for that day -- Thanks

[AndyPowerAppNew]

I think with my current code the checkout stamp only works if there is 1 record in the sharepoint list, which isnt great as there will be lots of people using in dureing a working day, is there anything we can do to fix ?

[poweractivate]

@AndyPowerAppNew 

1. No that's not correct, there is more than one record, the issue is you can't test it from your own account though, you need to create multiple Office 365 accounts and sign in and out of them to test my solution.

A person in your organization will be using their own Office 365 account, not logging in to yours, right?

If you keep using only your own account all the time you cannot test the solution I gave you properly.

2. The only way to really test #1 is to have multiple Office 365 accounts and sign in and out of them to test that User().Email is working correctly. Go to admin.microsoft.com to create them or ask your admin to create some for you. Then you'll see there's more than one Record in there.

Having a "dropdown" to simulate real sign in and out activity of your app is not a very good simulation at all.

Making a dropdown because that's the only way you can conceptualize how to test the app is a really bad habit to get into too.

If a user has to select their own name from a dropdown to sign in, because you yourself as the developer actually needed the dropdown yourself to test the app, because that was the only way you could test it, that's really bad . It's bad because then the apps are not user-centric or trying to solve a user's problem - instead, you're trying only to solve "your own problem".

Could you imagine if every time you logged into a website, you had to select your own username from a list of usernames, because the developer only knew how to test the app with a dropdown that had the list of everyone's usernames, and had to select it first before doing anything else? After that, you click "Sign In" and presto! You're signed in as anyone you want from the whole database?! 

Suppose Microsoft implemented Office 365's authentication that way - would you ever use Microsoft's services again if they did that?

What about a list of social security numbers and credit card numbers? If the developer had to have a dropdown, why doesn't the developer tell you to sift through the private social security numbers, addresses, and credit card numbers of every person in the database, and ask you to go ahead and find yours first in that list in that pile, so you could verify that you are who you say you are?

The problem is, anyone else can just say they're anyone at that point, right?

 What's worse is that in attempting to "solve your own problem" you actually are adding unnecessarily complexity and made it harder for yourself too. To implement a whole dropdown, select a name for a dropdown, and do all that unnecessary work just to make functionality that's harder for both yourself and an end user to test, use and maintain. See if you could try to avoid this habit if you can generally.

1. There is not only one entry. There is only one entry for YOU - but there is another entry if you are signed in as someone else.

1. You don't need any dropdown list. Someone can easily select another person if you had a dropdown list.

2. If you only need the last sign in date/time and last sign out date/time, then the solution I gave is working fine. 

"for the day" is not clear. Someone could sign in today and then sign out one week later, right?

Do you need to keep track of multiple sign ins from one person for a day, and then delete them automatically every day too? What if they never sign out until next week though?

This sounds like it may be more complex than just keeping the solution as I gave it, where the sign in date/time and sign out date/time is kept and overwritten each time they sign in or out.

It's not clear what you meant, do you need the Sign In Date/Time and Sign Out Date/Time to be kept in storage for some reason, and if so, what are you going to do with all that data, exactly?

Do you need to show information to someone about when someone signed in and out, and for this information not to be overwritten but kept instead?

Do you need to show a list of when someone was signed in and out in the past?

Even if it's "for the day" it may ultimately mean you have to keep track of it. If you will delete it or never use it immediately, then you don't need it. If you need it later, then you may need it. Someone may be signed in today and sign out tomorrow - someone else may sign in today and sign out next week!

3. You cannot test it unless you sign in as another person in Office 365 first.  If you could sign in to another Office 365 account then it would create a separate record.

See if it helps @AndyPowerAppNew 

P.S. Try not to add that dropdown to select among a list of people for sign in, it's still unclear why you even need it. You shouldn't test the app that way, you should test from another Office 365 Account in your organization to see if it creates the separate record, and use the solution as I gave it.