The purpose of this document is to discuss methods of provisioning person records in the Registry.
When reading this document it is important to distinguish between a UUPID and a person record.
A UUPID is an attribute of a person record.
A person record in the Registry can exist without a UUPID, but a UUPID cannot exist without being tied to a person record.
A person needs a UUPID to access services; it is part of their credential.
The process of provisioning a person record at Virginia Tech currently requires a strong affiliation to the University.
Students, Employees, and Alumni all exist in Banner and their records replicate to the Registry.
Once a person's record exists in Banner, an eligible individual can create a UUPID in the Registry.
The Registry is the system of record for a very small number of attributes:
Banner is the system of record for all other attributes.
This solution allows anyone to create a UUPID.
A weak affiliation means that the university's enterprise database houses little to no information about the person.
The major problem with a system that provides both weak and strong affiliated people is the process required to move people between these two states.
This problem is complicated even more by the fact that the current production system only provides for strong affiliations.
Any solution must have minimal impact on the current state of affairs.
Current VTPEOPLE Schema:
|VTPEOPLE_UID||this column can no longer be the primary key|
|PREF_LAST_NAME||remove, duplicated from VTPEOPLE_NAMES|
|PREF_FIRST_NAME||remove, duplicated from VTPEOPLE_NAMES|
|PREF_MIDDLE_NAME||remove, duplicated from VTPEOPLE_NAMES|
|PREF_SUFFIX||remove, duplicated from VTPEOPLE_NAMES|
|PREF_PREFIX||remove, duplicated in VTPEOPLE_NAMES|
|BANNER_PIDM||move to VTUSERIDS|
|BANNER_IDNUM||move to VTUSERIDS|
|SSN||move to VTUSERIDS|
Future VTPEOPLE Schema:
|VTPEOPLE_SEQNO||new primary key for all support tables to reference|
|VTPEOPLE_UID||identifier for strong affiliated people|
|VTPEOPLE_RUID||identifier for weak affiliated people|
With the new schema a record in VTPEOPLE must have either a UID or a RUID, but never both.
In addition, weakly affiliated people won't have empty data fields as they have all been moved to support tables.
All Banner specific fields have been out of the VTPEOPLE table.
Weakly affiliated people can also have all the attributes associated with strongly affiliated people as the support tables, such as NAMES and EADDRESSES, reference the VTPEOPLE_SEQNO, not the VTPEOPLE_UID.
these systems would benefit from a weak affiliation solution.
Prospective employers, admissions officers, and accreditation officials might want access to student portfolios.
Some of these accounts might have limited life spans (particularly prospective employer access).
Financial institutions might need access to user-authorized data for employees such as pay rate and job history.
These accounts would likely be granted to individual representatives of financial institutions for limited period of time.
Parents, relatives or employers may need access in order to pay tuition and fees for a student.
Infinet may offer a solution to this problem in the form of pay accounts, but the university may wish to offer accounts to these users for other purposes in addition to fee payment.
Remote collaborators on open source projects may need access to local code management repositories.
A staff member of the Web Hosting group is using a special subversion instance specifically for collaborative development projects.
Other IT staff across campus may be interested in initiating or participating in similar activities.
Friends, relatives, and other acquaintances may want access to published, restricted Web content on a local Web site hosting service.
Filebox currently supports users without UUPIDs by allowing filebox users to create accounts for those users.
The account ids take the form of filebox.username.
Accounts to enable access for non-VT people who want to access content within an institutional repository.
Default system behavior for Dspace, as an example, is to offer the user the opportunity to create an account based on an email address.
Accounts for remote researchers to give them the ability to access locally managed collaborative environments, such as sakai.
Default system behavior for Sakai is to offer the user the opportunity to create an account based on an email address.
Temporary wireless network access accounts for non-VT affiliates.
This solution requires a person to authenticate themselves with demographic data before a UUPID can be created.
(Implies a Banner record already exists for the person.)
This is the solution we have now.