People

Owned by Dan Franko (Unlicensed)
Last updated: Dec 17, 2014
3 min read

IST

IST-User 

Data

Database: ISTx

select * from yuids.svc_now_ppl_v

Mapping

Eureka Considerations

I believe we can replace all of this with the IDR service.

DWH

DW - Manager 

Data

Database : DWHx

select distinct
ee.Yale_UPI UPI, 
supv.yale_UPI supv_upi,
facit.asgn_people_id FACIT_PPL_ID
from 
  YUDW.YUHR_HP_SERVICE_CUR_V ee
, YUDW.YUHR_HP_SERVICE_CUR_V supv
, (select ee2.asgn_people_id asgn_people_id from YUDW.YUHR_HP_SERVICE_CUR_V ee2 where 
   ee2.division_cd = 'D00433'
   --and ee2.assignment_primary_flg = 'Y'  This addresses item #1 - should we implement this?
   and NOT EE2.assignment_per_status_typ = 'TERM_ASSIGN'
   and( ee2.job_cd in ('FAC', 'FEL', 'PDA', 'PDF')
   OR (EE2.POSITION_NM LIKE '%Lect%' or ee2.position_nm like '%Prof%'))) FACIT
where 
    ee.supervisor_id = supv.asgn_people_id (+)
and ee.asgn_people_id = FACIT.asgn_people_id (+)
and NOT EE.assignment_per_status_typ = 'TERM_ASSIGN'
and ee.assignment_primary_flg = 'Y'

Mapping

Eureka Considerations

Manager and facit information aren't available in IDR, but we might be able to get it in there.

DW - Division

Data

Database : DWHx

select 
division_cd,
division_nm,
department_cd,
department_nm,
organization_unit_cd,
organization_unit_short_nm,
organization_unit_nm,
senior_director,
lead_admin_pos_netid,
ops_mgr_pos_netid 
from yudw.yugl_organization_dm_cur_v

Mapping

Eureka Considerations

Manager and facit information aren't available in IDR, but we might be able to get it in there.

DWH - Department

Data

Database : DWHx

select 
division_cd,
division_nm,
department_cd,
department_nm,
organization_unit_cd,
organization_unit_short_nm,
organization_unit_nm,
senior_director,
lead_admin_pos_netid,
ops_mgr_pos_netid 
from yudw.yugl_organization_dm_cur_v

Mapping


Eureka Considerations

Should we pull in department info for each user from IDR and this information separately to drive the list?

AD

Do we need any of these?  Can't we get the mobile number from somewhere else?  We pull source as well, which is the ldap connection string, but it's not clear if that's even needed since user_name is used for shib.  Storing the groups in the AD only has one advantage and that is that all environments get their membership from one place.  No one else uses the AD group membership however, so it might not make sense to maintain it in the AD. Dan Franko (Unlicensed)

Yale AD/Users

LDAP Target

Mapping

Yale AD (SOM)/Users

LDAP Target

Mapping

Yale AD/Groups

LDAP Target

Mapping

Eureka Considerations

Should we manage groups inside or external to the system, that is the question.