Field Name | Module | Contributor | Description | Data Source | Data Location | First introduced | Controlled Vocab Options | Tied to Scripps Scholar |
| | | | | | | | | |
| Dept Affiliation (Select Business Office): | Employment / HR | | lists all appointed depts, the selected item indicates "Business Office" ( see Business Office below ). Comes from PPS Employee field: "Dept. All" which is a concatenation of Dept Codes (don't know how dept codes are determined but could be tied to Appointments ). Dept codes are looked up with our internal Contact DB, "dept_lookup" table. | PPS but allows for "local" values | | V1 | | |
| Business Office | Employment / HR | | people_values field "business_office", not pre-populated so clients should fallback to home_dept if business_office == NULL). | | people_values | V1 | | Yes |
| Home Department | Employment / HR | | Home Department follows the person's FTE. That's why we've decided to use the PeopleDB to supply the Scripps Scholars site with Home Dept. information via the Business Office field. | home_dept = pps_employee.home_dept_code ("codes" are translated using contact.dept_lookup ) no pps_appointment fields are used here. | people_values | V1 | | |
| Dept (Add New to List): | Employment / HR | | Provides ablitiy to add an affiliated department not present in Dept Affiliation list. | dept = pps_employee.emp_all_depts ("codes" are translated using contact.dept_lookup ) no pps_appointment fields are used here. | people_values (can have multiplt entrees) | V1 | | |
| Publish Profile | | | As of Aug. 2014 these heuristics may no longer be used: Three (3) states subdivided by role: 1. Field is blank (default) : A) For students: only show name and email address for students. B) show everything for For staff and faculty . : show everything 2. NO: A) staff = For students: only name and email address B) students = For staff and faculty: only name and email address 3. YES . : All data is displayed for both students /, staff & faculty | | | V1 | | |
| Exempt | Employment / HR
| | Jerry recommended adding this field after learning nonexempt employees will be sub 2 positive time reporting biweekly, starting January 2013. | PPS: Binary values are 1 or 0 and are found here: sio_people.pps_appointment.app_flsa_exemption_flag | | V1 | | |
| Primary Email | Employment / HR | | Official UCSD email. Pulled from PPS. Used for MegaSite if no Display Email is selected. | | | | | |
| Display Email | Employment / HR | | Needs to be selected in People app. Used for MegaSite and SS. | | | | | |
| Business Office Section | Employment / HR | | Auto-filled based on ““Business Office” selected in "Dept Affiliation" field. Ended up creating a new people_values field "biz_section" that actually stores (therefore can be queried) the translated value from "business_office" value (if exists) | | people_values | | | |
| Phone (all) | Employment / HR | | for Local data it's not enforcing but makes user feel bad if format is not (xxx)xxx-xxxx . Offie and Fax pulled from Blink are usually is format (xxx)xxx-xxxx. | | | | | |
| is_supervisor | Employment / HR | | is_supervisor values are completely local, i.e. do not get updated whenever the cron runs. Overrides are there to prevent local changes from being overwritten by the "official" data sources, and get inactivated once the predefined conditions fail. And in this case, for example, since is_supervisor = Yes didn't get deleted during today's cron update, condition of "IF is_supervisor = Yes does not exist" fail, and that particular override inactivates. I | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| Academic Voting Section | Employment / HR | | | | people_values | | | |
| | | | | | | | | |
| Middle Name | Employment / HR | | Helpful in determining if record already exists. | | | | | |
| NIckname | | | Blink doesn't allow letters with accents or punctuation marks. Local field does allow these. | Blink | | | | |
| | | | | | | | | |
| Working Title | Employment / HR | Diane Boomer | "Working Titles" don't appear in PPS at all. I suspect that they initially come to the BLINK Directory from the employee's Job Description card. I have attached a sample Job Description - an old one of mine. After that, the BLINK Title (synonymous with our 'working title) can be edited by the employee or anyone authorized to make changes to the employee's BLINK directory listing. If the employee never bothers to review and update his/her title in the BLINK Directory, there's probably no other update mechanism, and the Title remains the same despite promotions or reclassifications. I just noticed a similar case (again, thanks to People App) for Gregory Roberts. His working title in the app was "Asst Proj Sci" even though he was promoted to Assoc Researcher a few years ago. I looked him up in the BLINK Directory. Sure enough, his title there was "Asst Proj Sci." I requested a BLINK directory update to change his title to associate researcher in the directory listing. I expect the update will go into effect tomorrow. Again, this has nothing to do with PPS. His PPS appointment titles are all up to date. Working Title is not a PPS field. | Blink's Employee Title defaults to its payroll title. However, a working title can be used as well, but not both. Working title is manually entered by either the Directory Contact or Directory Services.
via Fema | | V1 | | |
| SIO Status | | | Controlled vocab: See Options. | | | | RTAD Pending, Appointment Pending | |
| Publish Directory Info | | | field has 3 states: 1. A) Field is blank (default) directory info depends on the PPS Status and SIO Status. i.e if person has been separated in PPS and no SIO Status has been selected, then the person will be removed from directory. If person has been separated in PPS and the SIO Status has any of the choices considered to be 'active', such as RTAD, then the person will not be removed from directory. If SIO Status is 'Past Affiliate' selected then the person will be be removed from directory. B) If record is set to NO, then person will not show up in directory irrespective of their PPS and SIO Status. Trumps everything. C) If record is set to YES, then person will show up in directory irrespective of their PPS and SIO Status. | | | | v1.2b | blank/Yes/No | |
| | | | | | | | | |
| | | | | | | | | |
| Supervisor | Relationships Module: | | | campus Timekeeping | | | | |
| Supervisee | Relationships Module: | | | campus Timekeeping | | | | |
| Work Director | Relationships Module: | | | campus Timekeeping | | | | |
| Work Directee | Relationships Module: | | | campus Timekeeping | | | | |
| Advisor(s) & Advisee | Relationships Module: | | | FMP | | | | |
| PI/Sponsor | Relationships Module: | | | Local - | | | | |
| | | | | | | | | |
| | | | | | | | | |
| Country of Citizenship | Personal Data | | The Country of Citizen data are considered Sensitive and should have limited visibility in the DB. Not sure how limited or what mechanism we'll use to keep it limited, if indeed it's needed at all. I suspect that it's needed for issues like Export Control, where visitors or students from sanctioned countries need to be identified so that funding agency export control requirements are met. | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| Occupying Space | Space | | marking an occupying space as "Primary Space" writes to marinara's space.sio_occupants.primary = "Y" (note that "primary" is a MySQL reserved word; use `primary` in query). history IN people coming FROM space db app AND primary space history IN space | Local - | | | | |
| | | | | | | | | |
| Assigned Space | Space | | for V1.0 "Assigned Space" is not saved. will disable the edit field for V1.0 release. however it's only designed to assign a person to a space that's not assigned to somebody else (this app will not kick existing assignees out), it's probably a better idea to simply link to the space db. | Local - | | | | |