Additions

Added content from the wiki for pages labeled as CO306

_episodes/02-comanageRoles.md

@@ -28,6 +28,8 @@ COmanage uses roles to manage the functionality that different users can use. Th
 * **Audit** - The ability to review and report on historical actions taken within COmanage
 * **System Administration** - For the technical maintenance of COmanage
 
+ NOTE: this list needs to be reconciled against the table of Registry Permissions](https://spaces.at.internet2.edu/display/COmanage/Registry+Permissions)
+
 ## Administrator Roles
 
 COmanage Registry defines three types of administrators.
@@ -68,6 +70,40 @@ System Administrators have privileges that enable them to maintain the COmanage
 
 <Needs a description>
 
+### Group Owner
+
+<Needs a description>
+
+### Group Member
+
+<Needs a description>
+
+### CO Person
+
+<Needs a description>
+
+### Anonymous
+
+<Needs a description>
+
+### 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:
+
+CO Administrators
+CO and COU Administrators
+Members of a specified CO Group
+Any valid CO Person
+The sponsors capability may also be disabled. This may be advisable for deployments with large user populations, as disabling sponsors will reduce some database querying.
+
+If a sponsor subsequently becomes ineligible to be a sponsor, they will remain as sponsors for any existing records. However, they may not become sponsors of new records, and any existing record must specify a new sponsor if edited.
+
+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)).  
+
 ## Managing Roles
 
 ### CO Group Membership and Enrollment

_episodes/03-comanageGroups.md

@@ -16,6 +16,8 @@ keypoints:
 
 Groups are used for a variety of reasons, but generally they are used to manage permissions and access, or to manage contact lists. COmanage handles basic groups; for more complex group structures, Grouper integration is required.
 
+COmanage Groups (CO Groups) are defined at the CO level, and CO Group Memberships attach to the [CO Person](https://spaces.at.internet2.edu/display/COmanage/Understanding+Registry+People+Types). CO Groups are fairly basic, for more sophisticated needs COmanage can be connected to [Grouper](http://grouper.internet2.edu/) using the [Grouper Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/Grouper+Provisioning+Plugin). By default, any CO Person can create a new CO Group.
+
 ## What you need to consider
 
 CO Groups provide basic group functionality enabling actions to be applied to all members of the group at the same time, for example, granting access to an application, joining a mailing list, or expiring membership at the same time.
@@ -47,6 +49,18 @@ Some will require more sophisticated group management than what is available in
     * Suspended - Useful if you are not ready for your group to be active.
 5. Click 'Add'.
 
+## Group Attributes
+
+### Open vs Closed
+
+An _open_ group is one that allows anyone to join. Participants can self-join, no administrator action is required. Memberships in a _closed_ group can only be set by the group owner.
+
+In addition, CO Administrators can manage any CO Group within their CO.
+
+### Automatic Groups
+
+_Automatic Groups_ are those which Registry automatically manages the memberships of. 
+
 # Group Members
 
 A group member is simply a participant in the group. A group owner has permission to add and remove members to and from the group, including closed groups. A CO Person can be a member, and owner, both, or neither.
@@ -62,11 +76,45 @@ There are several ways to add individuals to groups. This may be done as part of
 3. Select a user and click on 'Manage Group Memberships'. This will show a list of available groups and you can add the individual as a group member or as a group owner by clicking on the appropriate box in the 'Actions' column.
 4. Click 'Save'.
 
+## Using Enrollment flows for CO Group Memberships
+
+CO Group Memberships can be added as part of an [Enrollment Flow](https://spaces.at.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration) by adding an attribute of the appropriate type. For more details, see [Registry Enrollment Flow Configuration](https://spaces.at.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration).
+
+CO Group Memberships can also be added via [Organizational Identity Sources](https://spaces.at.internet2.edu/display/COmanage/Organizational+Identity+Sources) when connected to [Pipelines](https://spaces.at.internet2.edu/display/COmanage/Registry+Pipelines).
+
+## Nested Group membership
+
+As of Registry v3.3.0, Nested Groups allow the members of one group (the "nested" or source group) to automatically be included as members of another group (the "target" group). Nested Groups only confer group membership, they cannot be used to manage group ownership. Currently, Nested Groups are additive only, it is not possible to specify certain members to be excluded from the target group ([CO-1585](https://bugs.internet2.edu/jira/browse/CO-1585)).
+
+To nest a group, edit the target group and click **Add Nested Group**. Select the desired source group. Currently, only CO and COU admins can create or remove nestings.
+
+Nested Groups do not imply any sort of hierarchy ([CO-1223](https://bugs.internet2.edu/jira/browse/CO-1223)).
+
+> Nested Groups are not designed to scale to very large groups, and in particular manual reconciliation of a very large group with one or more Nested Groups may be problematic. The exact threshold will vary according to the specifics of a given deployment. Deployments experiencing problems reconciling large groups may wish to consider a solution such as [Grouper](http://grouper.internet2.edu/).
+
 ## Remove a Group Member
 
 There are several ways to remove an individual from group membership, either by managing that individual directly (follow the directions for Adding a Group Member and click on the appropriate box to de-select that entry) or by managing the group as a whole. The instructions below assume direct group management instead of per-individual management.
 
 1. Login to the COmanage Registry (if you haven't already) and select your CO from the list.
 2. Select 'My Groups' from the Group drop-down menu.
 3. Select the group you are changing (note that you must be an owner of that group to adjust membership).
-4. Click on 'Delete' for each member you are removing from the group, and 'Remove' from the verification pop-up.
+4. Click on 'Delete' for each member you are removing from the group, and 'Remove' from the verification pop-up.
+
+As of v3.1.0, it is possible for a CO Person to add or remove themselves from the CO Group associated with a Service directly from the Service Portal, using the _Join_ and _Leave_ buttons. Using _Join_ and _Leave_ is functionally equivalent to navigating to My Groups, finding the appropriate group, and ticking the Member button. This is only available when the CO Group associated with a Service is an open group.
+
+> Administrators cannot use this interface on behalf of a CO Person, but must instead use the regular group management interfaces.
+
+## Reconciling group memberships
+
+In general, nested group memberships and memberships of automatic groups are updated in real time as needed. However, If an automatic group or a group with nested groups appears to have incorrect group memberships, the group may be manually reconciled to fix incorrect memberships. To reconcile a group, edit the desired group and click **Reconcile**.
+
+Manually reconciling a group will not automatically reconcile related groups. For example, if Group A has nested Group B which in turn has nested Group C, and Group C is manually reconciled, it will probably be necessary to also manually reconcile Group B.
+
+## CO Group Membership Attributes
+
+### Member vs Owner
+
+A group member is simply a participant in the group. A group owner has permission to add and remove members to and from the group, including closed groups. A CO Person can be a member, and owner, both, or neither.
+
+The CO Person who creates a CO Group is automatically set as both a member and owner of the new group.

_episodes/05-groupFeatures.md

@@ -0,0 +1,62 @@
+---
+title: "Group features"
+teaching: 20
+exercises: 0
+questions:
+- "Question here"
+objectives:
+- "List the objectives"
+keypoints:
+- "List the key takeaways for the episode"
+---
+
+# CO Email lists
+
+Email Lists are data structures that associate [CO Groups and Group Memberships](https://spaces.at.internet2.edu/display/COmanage/CO+Groups+and+Group+Memberships) with listservs. Email Lists are available as of Registry v3.1.0.
+
+Registry does not provide actual message delivery capabilities, but rather maintains metadata about lists in order to provision list management software using [Provisioner Plugins](https://spaces.at.internet2.edu/display/COmanage/Provisioning+From+Registry) that support Email List objects. Email List-aware provisioners include:
+
+* [LDAP Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin) (not yet implemented, [CO-1439](https://bugs.internet2.edu/jira/browse/CO-1439))
+* [Mailman Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/Mailman+Provisioning+Plugin)
+
+Several groups can be attached to an Email List in order to define both list membership and roles for the list. The following are currently supported:
+
+* Members
+* Administrators
+* Moderators
+
+As an example, if you create a email list called "Researchers" and attach the CO Group "Biologists" as its members group, then any valid CO Person who is a member of Biologists will be subscribed to the Researchers list in the mailing list management software. The actual privileges assigned to members, administrators, and moderators are determined by the specific mailing list software.
+
+The list name will typically become the left hand side of the list's email address.
+
+## Email list data structure
+
+You can find the registry data model for CO mail lists in the [wiki: cm_co_email_lists](https://spaces.at.internet2.edu/display/COmanage/cm_co_email_lists)
+
+# Registry services
+
+As of v2.0.0, COmanage Registry supports a concept of CO Services. A CO Service represents a service or application that a CO Person has access to by participating in the collaboration. While access to the service is likely controlled by Registry managed attributes, the service itself is not accessed as part of Registry. Instead, CO Services act as inventory or catalog of available services, rendering a list of available services on a per CO Person basis.
+
+CO Services are registered by a CO Administrator via the Configuration >> Services menu, and are made visible to users via both the Services menu (v2.0.x only; visible only after the first CO Service is registered) and the Service Portal (available in the main menu). CO Service attributes include
+
+* **CO Group**: Access to this service is available only to members of this group. Note the application is ultimately responsible for its own access control.
+* **Service URL**: The URL of the service.
+* **Logo URL**: The URL for an image that represents this service. If you'd like to serve these locally from your Registry server, see [Publishing Images and Other Media](https://spaces.at.internet2.edu/display/COmanage/Publishing+Mostly+Static+Public+Content).
+* **Contact Email**: The email address of a contact responsible for managing the service.
+* **Entitlement URI**: The [entitlement URI](http://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonEntitlement) associated with this service. Used (eg) by the [LDAP Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin).
+* **Visibility**: Who can see this CO Service entry. Note that administrators are not treated specially – they will only see Services in the menu and portal for which they have associated eligibilities. To see the full list of services, administrators can use the configuration menu.
+  * **CO Admin**: Only CO Administrators within the CO can see this service
+  * **CO Group Member**: Only members of the associated CO Group can see this service
+  * **CO Person**: Any CO Person within the CO can see this service
+  * **Unauthenticated User**: Anyone can see this service
+* **COU**: COU this CO Service is associated with. Service Portals will be available (in the main menu) for each COU with attached services. If set, this service will not be visible in the CO's Service Portal. Available since Registry v3.1.0.
+* **Service Identifier Type**: Used to indicate which type of [Identifier](https://spaces.at.internet2.edu/display/COmanage/cm_identifiers) is to be used with this Service. Available since Registry v3.2.0.
+* **Short Label**: Primarily intended for use with the [LDAP Provisioning Plugin](https://spaces.at.internet2.edu/display/COmanage/LDAP+Provisioning+Plugin), a short label for the service that can be used when attribute options are enabled. Available since Registry v3.2.0.
+
+If at least one CO Service is configured with Unauthenticated User visibility, then the Service Portal will be publicly accessible. Otherwise, only members of the CO can see the Service Portal.
+
+> The Service Portal can be rendered within [Registry Dashboards](https://spaces.at.internet2.edu/display/COmanage/Registry+Dashboards) by using the [Services Dashboard Widget](https://spaces.at.internet2.edu/display/COmanage/Services+Widget+Plugin).
+
+## CO Services data structure
+
+You can find the registry data model for CO mail lists in the [wiki: cm_co_services](https://spaces.at.internet2.edu/display/COmanage/cm_co_services)

index.md

@@ -25,6 +25,7 @@ Time | Section | Description
 00:10 | 2. [The Roles of COmanage](/episodes/02-comanageRoles) | Roles (Administrative and non-administrative)
 00:00 | 3. [Creating Groups](/episodes/03-comanageGroups) | How & why to create groups in COmanage
 00:00 | 4. [Special CO Groups](/episodes/04-specialGroups) | About some special groups in COmanage
+00:00 | 5. [Group features](/episodes/05-groupFeatures) | What are some special things that you can do with groups?
 
 
 _The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor._