Additional content for this lesson

_episodes/01-dividingCOsAndCOUs.md

@@ -46,3 +46,9 @@ Has Many | CO Person Roles; CO Departments | |CO People (via CoGroupMember); CO
 HIerarchical | Yes | No ([CO-1523](https://bugs.internet2.edu/jira/browse/CO-1523)) | No ([CO-721](https://bugs.internet2.edu/jira/browse/CO-721))
 Object Type | Structural Object | Primary Registry Object | Primary Registry Object
 Supported Attributes | None | Addresses; Email Addresses; Identifiers; Telephone Numbers; URLs; Leadership Group; Administrative Group; Support Group | Open / Closed; Managers (via CoGroupMember); Email Addresses (via CoEmailList); Identifiers (as of Registry v3.3.0)
+
+# Organizational Identities
+
+<Need description of these thing>
+
+Also see [Organizational Identity Sources](https://spaces.at.internet2.edu/display/COmanage/Organizational+Identity+Sources)

_episodes/02-comanageRoles.md

@@ -88,8 +88,6 @@ System Administrators have privileges that enable them to maintain the COmanage
 
 ### Sponsor
 
-<Needs a description>
-
 Each [CO Person Role](https://spaces.at.internet2.edu/display/COmanage/Understanding+Registry+People+Types) can have a sponsor attached to it. The sponsor can be selected via an Enrollment Flow Attribute, or subsequently by manually editing the record.
 
 The pool of eligible sponsors can be configured via CO Settings as follows:
@@ -104,6 +102,21 @@ If a sponsor subsequently becomes ineligible to be a sponsor, they will remain a
 
 Sponsor status may also be used in [Expiration Policies](https://spaces.at.internet2.edu/display/COmanage/Expiration+Policies). Note that expiration policies apply to the status of the sponsoring CO Person (ie: whether or not the CO Person is valid) and not to whether or not the CO Person is eligible to be a sponsor ([CO-1140](https://bugs.internet2.edu/jira/browse/CO-1140)).  
 
+## Permissions
+
+Generally, Registry permissions are based on the type of user a person is. These types are generally based on group memberships, and include administrative users as well as non-administrative users.
+
+Permission | CMP Administrator | CO Administrator | COU Administrator | Group Owner | Group Member | CO Person | Anonymous
+---------- | ----------------- | ---------------- | ----------------- | ----------- | ------------ | ------ | ---------
+Configure COmanage platform | (tick) | | | | | | 
+Configure CO | (tick) | (tick) | | | | | 
+Start Enrollment | | (tick) | If configured | | If configured | If configured | If configured
+Manage CO Person | (tick) | (tick) | (tick) within COU |  |  | See [Self Service Permissions](https://spaces.at.internet2.edu/display/COmanage/Self+Service+Permissions)
+Create Group | (tick) | (tick) | | | | (tick) | 
+Manage Group | (tick) | (tick) | | (tick) | | | 
+Add Self To Open Group | | | | | | (tick) | 
+Remove Self From Group | | | | | (tick) | | 
+
 ## Managing Roles
 
 ### CO Group Membership and Enrollment
@@ -120,4 +133,53 @@ CO Group Memberships can also be added via [Organizational Identity Sources](htt
 2. From the CO welcome page, click on the drop down menu for 'People' and select 'My Population'.
 3. Select the member that you would like to make into a CO admin.
 4. On the member's page, click on 'Manage Group Memberships'.
-5. Select 'member' on the admin group line.
+5. Select 'member' on the admin group line.
+
+# CO Person and Person Role Status
+
+Each CO Person Role has a status attached to it, and each CO Person has an overall status that is generally calculated as the "most preferred" of the attached CO Person Role statuses. Statuses represent various states in the identity lifecycle, and various statuses have specific meanings within COmanage.
+
+Status can be changed under various circumstances:
+
+* As part of [Enrollment or Invitation](https://spaces.at.internet2.edu/display/COmanage/Understanding+Registry+Enrollment+and+Linking).
+* As part of an [Organizational Identity Source](https://spaces.at.internet2.edu/display/COmanage/Organizational+Identity+Sources) and [Pipeline](https://spaces.at.internet2.edu/display/COmanage/Registry+Pipelines) sync.
+* Due to an [Expiration Policy](https://spaces.at.internet2.edu/display/COmanage/Expiration+Policies).
+* By updating CO Person Role validity dates.
+  * If a Role is in Pending status and the Valid From date is updated to be in the past, the Role will automatically change to Active status.
+  * If a Role is in Active status and the Valid From date is updated to be in the future, the Role will automatically change to Pending status.
+  * If a Role is in Expired status and the Valid Through date is updated to be in the future, the Role will automatically change to Active status.
+  * If a Role is in Active or Grace Period status and the Valid Through date is updated to be in the past, the Role will automatically change to Expired status.
+* Manually. Note that manual changes will be overwritten when an automatic update would result in a different status.
+
+The status of a CO Person is generally calculated from the status of the CO Person Roles attached. This happens automatically under the following conditions:
+
+* When a CO Petition is approved/the Enrollee becomes active.
+* When an Expiration Policy changes the status of a CO Person Role.
+* When updating a CO Person Role Valid Through date causes the CO Person Role to become Active.
+* When a Pipeline results in a status change.
+* When a CO Person Role status is manually changed.
+
+The CO Person status is set to the "most preferred" status of the attached CO Person Roles. "Most preferred" is currently defined as the order in the table, below. In general, active statuses are most preferred, followed by expired statuses (since there may have been skeletal records provisioned that need to be maintained), followed by invitation statuses.
+
+CO Person and Person Role Records are passed to [Provisioners](https://spaces.at.internet2.edu/display/COmanage/Provisioning+From+Registry) based on their status, as indicated in the table, below.
+
+> This table is effective as of Registry v2.0.0. For earlier versions, see [this page](https://spaces.at.internet2.edu/pages/viewpage.action?pageId=107020614).
+
+> In Registry v2.x and v3.x, this table is only supported by certain provisioners (Ldap, Crowd, LdapServiceToken). ([CO-1740](https://todos.internet2.edu/browse/CO-1740))
+
+Preference | Status | Description | Provisioning
+-----------| ------ | ----------- | ------------
+1 | Active | Person or Role is an active member in the CO | Person, Role, and Group data provisioned
+2 | GracePeriod | Primary association with the CO has ended, but services have not yet been deprovisioned | Person, Role, and Group data provisioned
+3 | Suspended | Association with the CO has been (manually) temporarily suspended | Person data and All Members Groups provisioned
+4 | Expired | Valid through date has been reached | Person data and All Members   Groups provisioned
+5 | Approved | | No data provisioned
+6 | PendingApproval | The enrollment flow petition is pending approval | No data provisioned
+7 | Confirmed | | No data provisioned
+8 | PendingConfirmation | An invitation or email confirmation was sent via an enrollment flow | No data provisioned
+9 | Invited | An invitation was sent via default enrollment | No data provisioned
+10 | Pending | | No data provisioned
+11 | Denied | The enrollment flow petition was denied | No data provisioned
+12 | Declined | The invitation sent via default enrollment was declined | No data provisioned
+13 | Deleted | | No data provisioned
+14 | Duplicate | The record is a duplicate of another | No data provisioned