Field Name | Module | Contributor | Description | Data Source | Data Location | First introduced | Controlled Vocab Options | Tied to Scripps Scholar |
Jump To... | Search | Tomo | Only meant to be a really quick "jump" to specific records using IDs. Used as a temporary solution until a proper search / landing page is spec'ed. This field can take - nickname
- SIO ID (people_id)
- Employee ID (eid)
- ISIS ID / Student ID (pid)
- partial name
- Simpson, Homer
- Simpson, H
- Simpson
- Homer
- Homer Simpson
- Homer S
- Simp
| | | | | |
| | | | | | | | | |
| Dept Affiliation (Select Business Office) aka 'dept' | 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. However, app. 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 | | For FTEs this field should be changed in PPS. 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. If a student doesn't have a PPS entry you can 'override' the field by hovering over the field on the top-rigth; once on the right spot you'll see a paper icon appear that you select; then you can type into the field. I don't recall if it auto-completes but just make sure it's the same spelling as other people with the same Home Department. | 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 Affiliation (Add New to List): | Employment / HR | | Provides ablitiy to add an affiliated department not present in Dept Affiliation list. Affiliations are loosely defined. For more granular membership use Business Office and Home Department. | 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 | Employment / HR | | 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 B) For staff and faculty: show everything 2. NO: A) For students: only name and email address B) For staff and faculty: only name and email address 3. YES: All data is displayed for students, staff & faculty <help>A 'Yes' means profile will be displayed on Scripps web site</help> | | | 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 | | | | | |
| HEERA | | | | PPS | | | | |
| SIO Role | Employment / HR | | Staff - Casual Restricted: Used primarily for undergrads working; don't have a Blink record and fields such as 'Phone' need to be 'overridden'. Academic - Teaching Professor: One of several roles used to populate Faculty List on Mega. The unique case of Geoffrey Cook (2015) | Local | | | | |
| | | | | | | | | |
| Academic Voting Section | Employment / HR | | | | people_values | | | |
| First/Last Name | Employment / HR | | | | | | | |
| 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. Can be used in Search fields. | Blink/Local | | | | |
| | | | | | | | | |
| 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. 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. 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 | Employment / HR | | ”RTAD”, “RTAD Pending,”Leave of Absence” and “Visa Pending” in SIO Status will be treated as “Active” in the Scripps Directory. Add: 'Sabbatical' and 'Appointment Pending'... should also be ‘Active’ Past Affiliate is 'Inactive'. | Local | | | RTAD Pending, Appointment Pending,... | |
| UCSD Status aka 'pps_status' | Employment / HR | | <help>This field is used to determine if record should be listed under Scripps Directory of the new website. Override to Active for this record to show up.</help> | PPS | | | | |
| Publish Directory Info | Employment / HR | | 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. | Local | | v1.2b | blank/Yes/No | |
| Directory Title | Employment / HR | | <help>Only used for Scripps Directory on Megasite; Takes ultimate precedence</help> This is the order of precedence used to establish which title will show on the Scripps Web “People” Directory: Directory Title > Display Title > Blink/Working Title > SIO Role For example, if the first three fields are blank, it will be the SIO Role that will show in the directory. - October 13, 2014 (via Edgar )Just an update: Megasite profiles and Scrippsscholars will now display Directory Title first if available as well.
| Local | | | | |
| TItle | Employment / HR | | Working Title. | Blink | | | | |
| Display Title | Employment / HR | | Used for academics only. Evolved from Scripps Scholars | Local | | | | |
| PPS Appointment Title | Employment / HR | | | PPS | | | | |
| | Employment / HR | | | Local | | | | |
| | | | | | | | | |
| 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 - | | | | |
| | | | | | | | | |
| SIO Separation and Departure Dates | Hiring/Separation | | If date is in the past the record becomes 'inactive' in People DB but record is still alive in the directory. ( True as of 3/2015) The heuristic for SIO Separation Date is working as it should but we need to have it translate to the directory. The most elegant solution would be that the end-user doesn't have to do anything more than having entered an SIO Separation Date or SIO End Date. Setting a directory flag in people_values could be a good solution, updated via a stored procedure tied to the end date check. | HR | | | | |
| UCSD Separation Date | Hiring/Separation | | should not show ‘Indef’ if the download = “that funky future date”. Instead, leave field blank. - e. g. Marie Nordstroem. | PPS | | | | |
| | | | | | | | | |
| | | | | | | | | |
| 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 - | | | | |