Skip to content

Commit

Permalink
Committing changes for today
Browse files Browse the repository at this point in the history
  • Loading branch information
lpaglione committed Oct 29, 2019
1 parent b0ca4cf commit 176f48f
Show file tree
Hide file tree
Showing 13 changed files with 223 additions and 1 deletion.
11 changes: 11 additions & 0 deletions _episodes/01-co.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
title: "The CO"
teaching: 20
exercises: 0
questions:
- "Question here"
objectives:
- "List the objectives"
keypoints:
- "List the key takeaways for the episode"
---
File renamed without changes.
11 changes: 11 additions & 0 deletions _episodes/02-cous.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
title: "The COUs"
teaching: 20
exercises: 0
questions:
- "Question here"
objectives:
- "List the objectives"
keypoints:
- "List the key takeaways for the episode"
---
File renamed without changes.
24 changes: 24 additions & 0 deletions _episodes/03-departments.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
---
title: "The Departments"
teaching: 20
exercises: 0
questions:
- "Question here"
objectives:
- "List the objectives"
keypoints:
- "List the key takeaways for the episode"
---

## 3. About CO Departments

CO Departments are primary objects within Registry, which means that they are intended to store representations of external objects (just like CO People). CO Departments can attach to either a CO or a COU, and can be used to store a number of attributes about the department, including telephone numbers, email addresses, URLs, identifiers, and the sets of people associated with specific responsibilities within the department. CO Departments can be used to support various use cases:

* In a VO deployment, CO Departments can be used to represent research groups.
* In an enterprise deployment, CO Departments can be used to represent the University department hierarchy.

While there may typically be a one-to-one relationship between CO Departments and COUs, it is not strictly necessary. For example, a COU maybe made up of members spanning two departments.

CO Departments are visible to anyone within the CO, by logging in to Registry, though only CO Administrators may edit their information.

CO Departments are specifically intended to be used with [Registry Services](https://spaces.at.internet2.edu/display/COmanage/Registry+Services) and the Service Portal.
File renamed without changes.
170 changes: 170 additions & 0 deletions _episodes/04-groups.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,170 @@
---
title: "The Groups"
teaching: 20
exercises: 0
questions:
- "Question here"
objectives:
- "List the objectives"
keypoints:
- "List the key takeaways for the episode"
---

# 4. About CO Groups

COmanage Groups (CO Groups) are defined at the CO level, and CO Group Memberships attach to the CO Person. CO Groups are fairly basic, for more sophisticated needs COmanage can be connected to Grouper using the Grouper Provisioning Plugin. By default, any CO Person can create a new CO Group.

# Comparisons

## Difference between CO Groups and COUs

The major differences between COUs and [CO Groups](https://spaces.at.internet2.edu/display/COmanage/CO+Groups+and+Group+Memberships) are

* Any CO Person can create a CO Group; only CO Administrators can create COUs.
* CO Group Memberships attach at the CO Person level, whereas COU memberships attach at the CO Person Role level.
* Management of CO Group Memberships is simple (e.g., manual management by the CO Group Owner, self-opt in for open CO Groups, etc.), whereas COU memberships can be managed using [Enrollment Flows](https://spaces.at.internet2.edu/display/COmanage/Registry+Enrollment+Flow+Configuration) and [Expiration Policies](https://spaces.at.internet2.edu/display/COmanage/Expiration+Policies).
* COU memberships imply CO Group Memberships (in the _Members:COU group_).
* Email Addresses can be attached to CO Groups via [CO Email Lists](https://spaces.at.internet2.edu/display/COmanage/CO+Email+Lists).

## Comparison Summary

| COU | CO Department | CO Group
---|-----|---------------|---------
**Belongs To** | CO | CO; COU | CO; COU (for automatic groups only)
Has Many | CO Person Roles; CO Departments | |CO People (via CoGroupMember); CO Email List
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)

# Plan your groups

## Why you want to use groups

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.

Some will require more sophisticated group management than what is available in COmanage. For these 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).

# Implement a group!

// NOTE: this section needs to be confirmed & screen shots added.


## Create a Group

![Interactive system activity](../assets/img/hands-on-keyboard.png)

**REQUIRED ROLE**: Platform Administrator (or maybe this is "Any CO Person?", at least by default.)

// NOTE: this section needs to be confirmed & screen shots added.

1. Login to the COmanage Registry and select your CO from the list.
2. Select 'All Groups' from the Group drop-down menu.
3. On the Groups page, select 'Add Groups', located above the Groups table.
4. Fill in the fields:
a. **The name of your Group.** This name will be displayed when your group is referenced. It is a good idea for this name to be descriptive, but relatively short.
b. **Description.** Write a short description of your group. This description will be helpful to users and future administrators to understand the purpose of the group.
c. **Open.** This is a check box to indicate whether anyone can join, or if users may only be added by the group owner. 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.
c. **Status.** There are three choices for the status:
* Active - you will select this one. Your group will be immediately active upon its creation.
* 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.

The CO Person who creates a CO Group is automatically set as both a member and owner of the new group.

## Add a Group Member

There are several ways to add individuals to groups. This may be done as part of the enrollment process, or it may be done after enrollment is complete and the individuals are already in the Registry. The instructions below assume enrollment has been completed and the individual is being added by a CO administrator to a new group.

1. Login to the COmanage Registry (if you haven't already) and select your CO from the list.
2. Select 'My Population' from the People drop-down menu.
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'.

## 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.

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.

## Admin Groups

Admin Groups are used to determine [Registry Administrators](https://spaces.at.internet2.edu/display/COmanage/Registry+Administrators). Admin Groups are automatically created when a CO or COU is created. The Platform Administrator typically sets the initial CO Administrator, and then the CO Administrators.

Since v2.0.0:

* The admin group is indicated by the group type GroupEnum::Admins and a null cou_id. The default name for the group is CO:admins.
* The admin groups for COUs are indicated by the group type GroupEnum::Admins and a non-null cou_id. The default name for COU admin groups is CO:COU:COU_Name:admins.

Prior to v2.0.0: <is this needed?>

* The admin group determines CO Administrators.
* Groups of the form admin:couname determine COU Administrators.

## Members Groups

Members Groups are automatic groups that are updated with all members of the CO or COU. Members Groups are automatically created and updated.

Since v2.0.0:

* Members of the CO in Active or Grace Period status are available in the group identified by the group type GroupEnum::ActiveMembers and a null cou_id. The default name for the group is CO:members:active.
* All members of the CO (except those in Deleted status) are available in the group identified by the group type GroupEnum::AllMembers and a null cou_id. The default name for the group is CO:members:all.
* Members of a given COU with an Active or Grace Period status role are available in the group identified by the group type GroupEnum::ActiveMembers and a non-null cou_id. The default name for the group is CO:COU:COU_Name:members:active.
* All members of a given COU (except those with only roles in Deleted status) are available in the group identified by the group type GroupEnum::AllMembers and a non-null cou_id. The default name for the group is CO:COU:COU_Name:members:all.

Prior to v2.0.0:

* The members group holds all CO People within the CO.
* Groups of the form members:couname hold all CO People with a role in the specified COU.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
8 changes: 7 additions & 1 deletion index.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,4 +34,10 @@ Time | Section | Description
00:00 | 7. [Making changes](/episodes/changesHappen.md) | It's impossible to anticipate all needs. How do you adjust your model when necessary?
00:00 | 8. [Advanced Topics](/episodes/advanced.md) | During this section we will review advanced topics of interest to the class. Some examples include: <list to come>

_The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor._
_The actual schedule may vary slightly depending on the topics and exercises chosen by the instructor._


1. [1. The CO](/_episodes/01-co.md) - Collaborative Organizations, what they are and how they are used
2. [2. The COUs](/_episodes/02-cous.md) - CO Units
3. [3. About CO Departments](/_episodes/03-departments.md) -
4. [4. About CO Groups](/_episodes/04-groups.md)

0 comments on commit 176f48f

Please sign in to comment.