| The Person document allows you to identify each user to KIM (and, by extension, to OLE). Each Person document includes data about a user's relationship with your institution as well as the roles and groups to which this person belongs. | ||||||||||
In KIM a person is a unique combination of an 'entity ID' and a 'principal ID.' The entity ID represents a person with a unique number, and the document associates the entity ID with the user's principal ID number and principal name (often referred to as a user name or user ID). When searching for or working with users in KIM, you usually reference either the principal ID or the principal name. A single entity ID can have multiple principals associated with it, but the base KFS implementation of KIM assumes that each entity ID has only a single principal. Patron names, addresses, emails, and some other information "live" in the KRIM tables, and there is a separate table OLE_PTRN_T, for the OLE-specific functions in the patron record. You can set up your patrons as KRIM persons, or keep them only in the patron file by loading them as an XML file. The workbook that details the KRIM tables required to describe an entity are here: https://docs.google.com/a/kuali.org/spreadsheets/d/1I6oInri-2WIGs-D1GKrDRgUafSRKXJ0oQIzzH_ibxoM/edit#gid=1262389168 Early adopters Chicago and Lehigh chose to import all their patrons and staff as KIM Persons, and then gave permissions to their staff. Michelle Suranofsky shared her scripts for creating the patron load: loadpatrons.php. Then she runs a script to convert staff patrons to KIM persons so they can be assigned permissions: stagepatrons.php |
General
Content
Integrations