...
Updating KNS System Parameters
The system parameters live in the work/db/rice-data/bootstrap/krns_parm_t.csv and work/db/rice-data/demo/krns_parm_t.csv files. All parameters are defined in each of these files. The reason for this is that a number of the parameters contain IU-specific data. Most of those parameters must be blanked out in the bootstrap dataset. During the import, the demo import process deletes all of the bootstrap-loaded parameters and replaces them with the demo versions.
- So, when adding new parameters: they must be added to both files.
- When updating parameters, check the value in both files to determine whether the bootstrap version should be set as well.
Updating KIM Data
The KIM data is (unfortunately) fairly complex to update through these CSV files, as there are a number of non-obvious dependencies. This will be rectified in the future, when the Rice project provides a method of XML ingestion for KIM data like it does for workflow documents. (But that's then, this is now...)
Roles/Permissions/Responsibilities
In general, these will all be defined in the bootstrap dataset files. These files set the roles defined by OLE and their relationships to permissions and responsibilities.
File | Description |
|---|---|
krim_role_t.csv | Role Definitions |
krim_perm_tmpl_t.csv | Permission Templates - usually should not need to be edited |
krim_perm_t.csv | KIM Permission entries - represent specific permissions within the application |
krim_perm_attr_data_t.csv | Permission details - specifies to what this permission applies |
krim_rsp_t.csv | KIM Responsibility entries - represent specific responsibilities within the application |
krim_rsp_attr_data_t.csv | Responsibility details - specifies to what document and route level this responsibility applies |
krim_role_perm_t.csv | Associates permissions with roles |
krim_role_rsp_t.csv | Associates Responsibilities with roles |
krim_role_rsp_actn_t.csv | For role/responsibility pairs for which all role members will be required to take the same action (APPROVE/ACK/FYI), there will be a record in this table linked to the unique ID of the role-responsibility record. |
People
Most people are defined in the demo dataset as they are only there for testing. In the bootstrap dataset, we only define the single "ole" user used for back-end processing. There should not be a need to add any other users to the bootstrap dataset. In the demo dataset, the following tables would need to be populated to add more testing users:
File | Description |
|---|---|
krim_entity_t.csv | The core entity linking object - really just a unique identifier |
krim_prncpl_t.csv | The principal (user ID) associated with an entity - may have multiple. |
krim_entity_ent_typ_t.csv | Defines the type of entity - currently always "PERSON", but they could have more than one. |
krim_entity_nm_t.csv | Name associated with a given entity/type combination |
krim_entity_email_t.csv | email addresses associated with a given entity/type combination (optional) |
krim_entity_afltn_t.csv | entity/type's affiliation with a given campus |
krim_entity_emp_info_t.csv | employee information associated with a given entity/type combination and affiliation (optional) |
krim_entity_ext_id_t.csv | Other identifiers associated with an entity. (optional) |
krim_entity_priv_pref_t.csv | Entity's privacy settings for FERPA (optional) |
Role Members
Role members can be defined in both the demo and bootstrap datasets. In this case, they augment each other. Role members can be principals, groups, or other roles.
In OLE, a large number of roles are composited out of other roles. These relationships are part of the base system which we will ship. Users and groups who may be assigned to these roles are not. So, when adding role members, those which are other roles should be added in the bootstrap directory, all others should be in demo.
File | Description |
|---|---|
krim_role_mbr_t.csv | Links the role member's unique identifier (role ID, group ID, principal ID) to the role. |
krim_role_mbr_attr_data_t.csv | Role Qualifiers - need depends on the role - but when present, determine the conditions under which the member is considered to have this role. (E.g., the user may only have this role when a document contains entries for a given chart.) |
krim_role_rsp_actn_t.csv | For roles which allow for the action (APPROVE/ACK/FYI) required by a workflow responsibility to be different for every role member, this table may have a row linked to the unique ID of the role member table. |