I. ESTABLISHED:
A. People
...
- if `display_title` exists use it
- else if `title` exists use it
- else if `sio_role` exists use it
- else if `pps_role` exists use it
II. PENDING:
III. Field Definitions:
...
...
Field Name
...
Module
...
Contributor
...
Description
...
Data Source
...
Data Location
...
First introduced
...
Controlled Vocab Options
...
Tied to Scripps Scholar
...
- Current List for PO Curricular Groups:
https://scripps.ucsd.edu/doctoral/program-areas/physical-oceanography-po
Question for Web Committee: Where should these folks maintain web visibility?:
Scripps Scholars
Scripps Profile
People Directory
Curricular Groups Member display ( do all members interact with students ??)
Additional question for Web Committee: What’s the protocol if member requests to not be listed?
Do we maintain web visibility for some and/or all of the following:
Scripps Scholars
Scripps Profile
People Directory
Curricular Groups Member display = Curricular Group Mentors ( i.e. interacts with students - students can contact these members) ??
2. Lal, Devendra : Should so deceased be set in sio_status. Scripts Profile is 'active' Should they be active in Scripps Scholars ?? On what pageShould there be mention of the Obit ??
III. Field Definitions:
| Table plus |
|---|
|
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 . However, 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 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 | | | 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 - | | | | | | | | | | | | | | | | | SIO Separation and Departure Dates | Hiring/Separation | | | | | | | | 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. | 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 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 -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. | | | | | | | | | | | | | | | | | | | | 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. | | | | | | | | | | | | | | | | | | | | | | | | | | 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 - | | | | |
|
...
Current List for PO Curricular Groups:
https://scripps.ucsd.edu/doctoral/program-areas/physical-oceanography-po
...
| | | | | | | | | | | 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 - | | | | |
|
IV. Attachments:
V. NOTES:
...
https://scripps.ucsd.edu/doctoral/program-areas/physical-oceanography-po***reference attachment 1A. for logic
Proposed People DB instructions to data stewards If Emeritus / Mentor (i.e. interacts with students)
Display Title: Emeritus
SIO Status - one of the following:
RTAD
RTAD PENDING
RETIRED
Question for Web Committee: Where should these folks maintain web visibility?:
Scripps Scholars
Scripps Profile
People Directory
Curricular Groups Member display
Additional question for Web Committee: What’s the protocol if member requests to not be listed?
Do we maintain web visibility for some and/or all of the following:
Scripps Scholars
Scripps Profile
People Directory
Curricular Groups Member display = Curricular Group Mentors ( i.e. interacts with students - students can contact these members) ??
*****
Pending Issues:
The SIO Separation and SIO Departure fields may not be getting checked to make someone ‘inactive’ , thus removing them from the Scripps web directory. (i.e. someone left Jan. 05, 2015 and was still in the directory. )_
• would remove that option from the SIO Role option list and the Display Title would be changed to 'Emeritus'. Moreover, if the SIO Status was changed to 'Emeritus', it would have a more powerful effect, such that the record would keep the person as 'Active' in terms of the People db, the Mega site directory, and by extension, SS, and their Scripps Profile. The SIO Status would thus trump UCSD Status. I would imagine SIO Status would also trump End Dates and Departure Dates but I don't have definitive notes on this. We definitely should iron out these rules. Similarly, we may also want to come up with definitive rules for when SIO Status = Deceased. Up to date, Tomo has hard-wired some rules for Lal and Ed F. to keep some of their information on the Mega site.
If PPS Status = 1
If "Is-retired"
****
Is_retired ??? Field: check it.
Lal, Devendra : Should so deceased be set in sio_status. Scripts Profile is 'active' Should they be active in Scripps Scholars ?? Should there be mention of the Obit on what page ??
If an academic 'leaves' we leave the SS sites 'active' for 6 months; use End/Departure Dates. post-docs/grads/emeritus/ (look at Display list )
• Directory 'active' = Profile 'active' (are made manually) Edgar has directory 'active' heuristic. If a profile is 'innactive' then the profile is not published.
Student List: Once entered you, the student stays on in perpetuity.
What happens to Lab Sites when PI 'leaves' ?? Jerry guesses the treatment is the same as their profile page ??
****
-oceanography-po
***reference attachment 1A. for logic
Proposed People DB instructions to data stewards If Emeritus / Mentor (i.e. interacts with students)
Display Title: Emeritus
SIO Status - one of the following:
RTAD
RTAD PENDING
RETIRED
*****
Pending Issues:
The SIO Separation and SIO Departure fields may not be getting checked to make someone ‘inactive’ , thus removing them from the Scripps web directory. (i.e. someone left Jan. 05, 2015 and was still in the directory. )_
• would remove that option from the SIO Role option list and the Display Title would be changed to 'Emeritus'. Moreover, if the SIO Status was changed to 'Emeritus', it would have a more powerful effect, such that the record would keep the person as 'Active' in terms of the People db, the Mega site directory, and by extension, SS, and their Scripps Profile. The SIO Status would thus trump UCSD Status. I would imagine SIO Status would also trump End Dates and Departure Dates but I don't have definitive notes on this. We definitely should iron out these rules. Similarly, we may also want to come up with definitive rules for when SIO Status = Deceased. Up to date, Tomo has hard-wired some rules for Lal and Ed F. to keep some of their information on the Mega site.
If PPS Status = 1
If "Is-retired"
****
Is_retired ??? Field: check it.
If an academic 'leaves' we leave the SS sites 'active' for 6 months; use End/Departure Dates. post-docs/grads/emeritus/ (look at Display list )
• Directory 'active' = Profile 'active' (are made manually) Edgar has directory 'active' heuristic. If a profile is 'innactive' then the profile is not published.
Student List: Once entered you, the student stays on in perpetuity.
What happens to Lab Sites when PI 'leaves' ?? Jerry guesses the treatment is the same as their profile page ??
****
Monday, October 13, 2014 6:31 PM
Luci, Carolyn,
Looking back through my notes, it was decided that the SIO Role would not change for Emeritus people. Instead, we would remove that option from the SIO Role option list and the Display Title would be changed to 'Emeritus'. Moreover, if the SIO Status was changed to 'Emeritus', it would have a more powerful effect, such that the record would keep the person as 'Active' in terms of the People db, the Mega site directory, and by extension, SS, and their Scripps Profile. The SIO Status would thus trump UCSD Status. I would imagine SIO Status would also trump End Dates and Departure Dates but I don't have definitive notes on this. We definitely should iron out these rules. Similarly, we may also want to come up with definitive rules for when SIO Status = Deceased. Up to date, Tomo has hard-wired some rules for Lal and Ed F. to keep some of their information on the Mega site. (Tomo says nothing is hardwired: Feb2015)
-luis