OTHER SLACK

[eaboettcher]

general: Dom Savio Yes sir

[eaboettcher]

general: Dom Savio

Yes sir

[eaboettcher]

#general: Dom Savio Yes sir

[eaboettcher]

#general: Chuck Kuo Hey channel, we covered a lot regarding testing today. We need to share with you what we learned sometime before we meet with Mike next week. I'm leaving the onus on the dashboard group to find a time that we can meet to discuss.

[eaboettcher]

#general: Chuck Kuo https://docs.google.com/spreadsheets/d/1BD5DWG3oTp3UGEsGZoVeirpfrK5KZ4Xt0i93oIp_tLI/edit?usp=sharing

[eaboettcher]

#general: Chuck Kuo Link to our schedule

[eaboettcher]

#general: Willie we will hit you up sometime before the end of Saturday with a plan

[eaboettcher]

#general: Willie @kuoc1 I can meet tomorrow at noon to go over Unit testing stuff. Most of the rest of my team is unavailable, but we're going to meet early on Wednesday for me to pass the info along. Let me know if that works for ya'll

[eaboettcher]

#general: Chuck Kuo (kuoc1) I'll come meet you and give you a brief overview. Enough to get you rolling

[eaboettcher]

#general: Troy Osland (oslandt) I can be there too, for moral support ya know

[eaboettcher]

#general: Conner McGrath (conner.mcgrath1) Me 3

[eaboettcher]

#general: Chuck Kuo (kuoc1) I'm not going to class but I'll see you guys at the project room

[eaboettcher]

#general: Willie (grossw) @kuoc1 naturally I didn't see these messages until just now; I've scheduled something else at around noon. It's 100% on me but I ended up with random crap strung together pretty much all afternoon. I'd offer to meet way later but our team is getting together at 6pm to work on a bunch of crap for this spring for PACCAR.

If @oslandt wants to send me that copy of your repository we talked about I'll take on the leg work of doing the research and bringing my team up to speed. I've done enough "figuring out how visual studio works" to be confident I can get the ball rolling if I can take a look at your setup. Obviously it would have been easier to go over it with you guys, but like I said, mea culpa

[eaboettcher]

#general: Chuck Kuo (kuoc1) Did troy end up getting it to you?

[eaboettcher]

#general: Willie (grossw) yeah, :+1:

I got our first set of tests built out. There are a couple bugs that are stopping them from running, but I got all the pieces in place and understand how they work for the most part

[eaboettcher]

#general: Willie (grossw) ditto the UTC stuff. I have the pieces in place, I just need to add a "hireDate" to our DataModel and then integrate that into all my methods and views. It's straightforward I just haven't had the time to do it yet.

[eaboettcher]

#general: Willie (grossw) but I have all the conversion methods etc where they need to be

[eaboettcher]

#general: Willie (grossw) !channel HEY NERDS. Everyone needs to join #git-hub and #update-alerts and make sure you get notifications from them. They will be central to working together effectively on this joint project!!

[eaboettcher]

#general: Chuck Kuo (kuoc1) @grossw do we want them to login using their Kenworth credentials and then check that against active directory?

[eaboettcher]

#general: Chuck Kuo (kuoc1) What's stopping us from just doing a regular login and storing their information independently of active directory?

[eaboettcher]

#general: Willie (grossw) afaik, their Kenworth Log in == their AD login. For certain applications anyway.'

[eaboettcher]

#general: Willie (grossw) if we can just use their AD for everything, that would be the dream

[eaboettcher]

#general: Willie (grossw) well, i dont think anything is stopping us at all.

[eaboettcher]

#general: Willie (grossw) but i might be easier if we only have to do one and not the other

[eaboettcher]

#general: Willie (grossw) if that makes sense

[eaboettcher]

#general: Chuck Kuo (kuoc1) So the reason we would want to connect to AD is so they don't need to register

[eaboettcher]

#general: Willie (grossw) well, we would just "register" their AD info

[eaboettcher]

#general: Willie (grossw) we would pull it from their windows session, like how Outlook automatically uses your user account to load your email on SU computers

[eaboettcher]

#general: Willie (grossw) they may end up having to punch it in manually, in which case we will store it in our table, and then have our system check it against AD on the back end

[eaboettcher]

#general: Willie (grossw) Option #3 is we just have a completely separate log in that we maintain in complete isolation from their AD account at PACCAR

[eaboettcher]

#general: Troy Osland (oslandt) I'm not quite sure how AD works yet but it sounds like it's built with the ability to link up different systems. So if we set up AD login, it should be able to connect to another AD like Kenworths. But this is only based off some skimming I did, not sure

[eaboettcher]

#general: Willie (grossw) but that would be the most work for us, if I understand the whole process accurately

[eaboettcher]

#general: Willie (grossw) ok so, AD is Active Directory. It's a Microsoft Database that's built into windows that lets companies store their employee's account info on a server, and then they can use that info to log onto any computer in the domain

[eaboettcher]

#general: Willie (grossw) like, when you go to control panel -> User Accounts, all thats stuff is stored in AD at a big company

[eaboettcher]

#general: Willie (grossw) its how an admin can reset peoples passwords or restrict their file permissions etc

[eaboettcher]

#general: Willie (grossw) if we used AD, we would get have some method that interfaces with their system's AD, (visual studio would obviously have some kind of protocol or library for doing so since they're both MS products)

[eaboettcher]

#general: Willie (grossw) and then when people tried to log in, we would take the Username/PW we get from our post form, and pass it to their AD via some API call

[eaboettcher]

#general: Willie (grossw) and get a response back from their system saying it checks out or not

[eaboettcher]

#general: Troy Osland (oslandt) Okay that makes sense

[eaboettcher]

#general: Willie (grossw) OR back to option 1, windows stores your AD creds in every local login session, if we can just pull that from the local computer, we can have it log them in automatically

[eaboettcher]

#general: Willie (grossw) again, the same way Outlook does

[eaboettcher]

#general: Willie (grossw) so in theory, the research you guys should do, is see what AD NuGet packages there are, and what types of actions/functions they support.

[eaboettcher]

#general: Chuck Kuo (kuoc1) Ok so my intuition is that we should use AD to verify but we should store the user info in our own db

[eaboettcher]

#general: Willie (grossw) there might be a call thats like "getLocalSessionCreds()" or something.

[eaboettcher]

#general: Willie (grossw) yes

[eaboettcher]

#general: Chuck Kuo (kuoc1) There is a nuget package for it where we can wrap access

[eaboettcher]

#general: Chuck Kuo (kuoc1) We need to use MS owin as well

[eaboettcher]

#general: Willie (grossw) because we aren't storing the info to verify their access necessarily. that was taken care of when they needed password to log into their computer

[eaboettcher]

#general: Chuck Kuo (kuoc1) Right we just store the info for us

[eaboettcher]

#general: Willie (grossw) we are just pulling their AD info so we can track actions they did etc