...
[17:21:52 CST(-0600)] <dmccallum54> this came up yesterday w/ CLC. sent you the relevant email
[17:28:00 CST(-0600)] <JasonElwood> That's helps. What if a coach doesn't exist in UP with a role?
[17:30:11 CST(-0600)] <JasonElwood> Nevermind. I think I found it.
[17:30:53 CST(-0600)] <dmccallum54> when they log in they'll get an unpleasant experience
[17:31:15 CST(-0600)] <JasonElwood> couldn't that happen with the SSO?
[17:34:39 CST(-0600)] <dmccallum54> depending on how the SSO works you could use attributes it passes to create a user just in time
[17:35:38 CST(-0600)] <dmccallum54> the way the Angel SSO worked, uPortal had to be able to find you either in AD or as a uP local user
[17:36:37 CST(-0600)] <dmccallum54> that's where it would get the attributes that put you into a security group
[17:39:18 CST(-0600)] <JasonElwood> sorry to keep at this, but. if the user only exists in AD with a role, then would we be able to query the role to look up the department_name from external_person to list the department in the report search criteria?
[17:40:52 CST(-0600)] <dmccallum54> ooookay
[17:40:55 CST(-0600)] <dmccallum54> 
[17:40:56 CST(-0600)] <dmccallum54> so
[17:41:07 CST(-0600)] <dmccallum54> we're definitely talking about coaches right now, right?
[17:41:17 CST(-0600)] <JasonElwood> yes
[17:42:40 CST(-0600)] <dmccallum54> if a coach is returned in the coach lookup API, then you know it at least has a person record, and it almost certainly has a external_person record from which that person record was derived. doesn't necessarily mean they also have a department listed in either of those records, of course
[17:43:28 CST(-0600)] <JasonElwood> cool. thanks
[17:43:47 CST(-0600)] <dmccallum54> so if all you want to do is list relevant departments in the report form you should be able to query the person record (with a join, actually)
[17:44:10 CST(-0600)] <dmccallum54> if you then want to filter the coach list in the report form, i.e. client side, by department, you probably have to change the API
[17:44:19 CST(-0600)] <dmccallum54> b/c i bet that info isn't included
[17:44:29 CST(-0600)] <dmccallum54> (you're getting some sort of PersonLiteTO or CoachLiteTO)
[17:44:45 CST(-0600)] <JasonElwood> yeah. I'm just trying to make sure we don't have any holes in the department list
[17:45:13 CST(-0600)] <dmccallum54> actually … looks like CoachPersonLiteTO does have dept name in it.
[17:45:24 CST(-0600)] <dmccallum54> the department list won't be comprehensive
[17:45:31 CST(-0600)] <JasonElwood> Ideally we should carry over the department when the person is created so we aren't querying the external_person table. But I think it is working as designd.
[17:45:35 CST(-0600)] <dmccallum54> i.e. it won't include depts for which we have no current person records
[17:46:27 CST(-0600)] <dmccallum54> ah… you're saying that the persons created by these coach lookup operations aren't immediately synced with the entire external record?
[17:47:39 CST(-0600)] <JasonElwood> not about time. department doesn't exist in person
[17:48:07 CST(-0600)] <dmccallum54> right… it's on an associated object
[17:48:34 CST(-0600)] <dmccallum54> PersonStaffDetails
[17:48:45 CST(-0600)] <dmccallum54> think that was what jim was querying
[17:49:09 CST(-0600)] <JasonElwood> ugh. missed that one. sorry. the sync is working then
[17:49:13 CST(-0600)] <dmccallum54> yah
[17:49:14 CST(-0600)] <dmccallum54> https://github.com/Jasig/SSP/commit/2cd1f2acbb1ee45f908263b44e66db7211d70c49
[17:49:50 CST(-0600)] <dmccallum54> i did check the coach sync code that runs when we pull the coach list… it's exactly the same function that runs for the background sync. so the dept should be set immediately
[17:50:15 CST(-0600)] <JasonElwood> its as immediate as everything else. so it works fine. thanks
[17:51:01 CST(-0600)] <dmccallum54> heh