diff --git a/_episodes/01-co.md b/_episodes/01-co.md index 3119059..72e491e 100644 --- a/_episodes/01-co.md +++ b/_episodes/01-co.md @@ -8,4 +8,76 @@ objectives: - "List the objectives" keypoints: - "List the key takeaways for the episode" ---- \ No newline at end of file +--- + +# 1. The Collaborative Organization (CO) + +## How are COs modeled in COmanage? + +COmanage is a multi-tenet tool. This means that for each installation, one or more top-level groups can be expressed. These groups are called Collaborative Organizations or COs. Individuals are added to these fundamental groups (COs), but once there, the individuals can be included in multiple sub groups of the CO, called Collaboration Organization Units (or COUs.) + +As a collaboration grows in size, it may be useful to create various structures to allow for delegation of person management operations and representation of organizational hierarchy. COmanage Registry supports this through the concept of CO Units, or COUs. As of Registry v3.1.0, CO Departments are also supported. + +### The COs + + The term “Collaborative Organization” or CO to refer to any formal or informal group of individuals that work collaboratively in a digital setting. They have a goal of a shared infrastructure that supports their collaborations so that the traditional limitations of localized applications may be overcome. Some traits of these COs include: + + * These individuals use a common workflow for adding collaborators. + * They share common policies for vetting the identities of collaborators. + * These COs may include individuals in a single organization, or individuals may be in multiple organizations, geographically different regions, or even work independently. + +COs can support one our more Collaborative Organization Units (COUs). + +# Administrator Roles + +COmanage Registry defines three types of administrators. + +## Platform (CMP) Administrators _(Also called Registry Admin in the documentation)_ + +Platform Administrators are effectively super users, with the ability to perform almost all operations on the platform. (Platform Administrators cannot execute enrollment flows for COs unless authorized by the enrollment flow.) + +Platform Administrators are configured by [adding the appropriate Organizational Identity](https://spaces.at.internet2.edu/display/COmanage/Default+Registry+Enrollment) to the COmanage CO, and then adding the corresponding person to the CO:admins group (v2.0.0 and later) or admin group (prior to v2.0.0) within the COmanage CO. + +The first user added as part of the [Registry Setup Script](https://spaces.at.internet2.edu/display/COmanage/Registry+Installation+-+Registry+Setup+Script) is automatically configured to be a Platform Administrator. + +## Collaboration (CO) Administrators + +Collaboration Administrators are super users _within a CO_. Collaboration Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the CO:admins group (v2.0.0 and later) or admin group (prior to v2.0.0) within the CO. + +CO Administrators can manage any CO Group within their CO. + +## System Administrators + +System Administrators have privileges that enable them to maintain the COmanage application. These capabilities include the ability to provision cluster resources (for example, hardware, virtual machines, etc), Register and maintain IP Addresses, administer application upgrades, manage and conduct operating system upgrades and conduct backups. + +--- + +< TO BE UPDATED > + +# Terminology & resources + +## COmanage Objects + +OBJECT | DESCRIPTION +------ | ----------- +`CO Person` :gear: | the representation of a person in COmanage +`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear: + +## Worksheets + +WORKSHEET | DESCRIPTION +--------- | ----------- +[Modeling Organization :memo:](/files/handouts/CO310-ModelingOrgs.pdf) | Planning sheet used in this lesson for understanding how the parts of the COmanage Organization fit together. +[CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance. + +## Slides + +To be included + +--- + +NEXT SECTION: [2. The COU](/_episodes/02-cous.md) + +LESSON OVERVIEW: [CO320 - Modeling Your Organization in COmanage](../index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) diff --git a/_episodes/01-old-modelingBenefits.md b/_episodes/01-old-modelingBenefits.md deleted file mode 100644 index d15940f..0000000 --- a/_episodes/01-old-modelingBenefits.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: "The benefits of good modeling" -teaching: 20 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -Why is this important? What does good modeling get you? What challenges can result from poor modeling? - -## Some review: What is COmanage again? - -COmanage is a Membership Management Service. These tools provide many things: - -* An interface for user enrollment -* The ability to assign rights and permissions to people through roles, groups, etc -* The ability to distribute the management of rights and permissions to multiple people. _For example, a project's Principal Investigator can manage the rights and permissions for his/her project group_ - -## Is modeling really all that important? - -Yes! One of the most useful features of COmanage is the ability to distribute the management of rights and permissions to multiple people. A little extra planning in the early stages of setting up COmanage can go a long way to making this delegation a straight-forward task. - -## Changing things later - -Of course, you can usually make changes to your initial model, though sometimes doing so is difficult and can necessitate a far-reaching rework of things that are working well as they are. We will discuss some fundamental considerations to make modeling decisions that you will less likely have to change. - -## MIND STRETCHER: Categorizing the components of a house - -Consider an empty house. If you think of all of the rooms in the house, there are several ways that you might group them. For example, you may group them based on the function of the room (places to sleep; places to eat), or you might group them by characteristics (rooms with or without water, type of floor covering). - -> Work in teams of 2-3 to list several ways that you may group the rooms in the house. [3 min work on their own - then ask for some examples - take 5-7 of them and write them on a flip chart] - -Now that you have some ways to group the rooms, work with in the same teams to pick a primary factor for grouping the rooms in the house from the list that you have or from the list that you see on the flip chart. Once you have that primary factor, pick 2-3 secondary factors that you think are important. For example, if you picked [the primary user of the room | pick something from the flipchart list], your secondary classifications might be, [the relative amount of time spent in the room | something from the flipchart] and [the function of the room | something from the flipchart list]. - -> Work in the same groups [5 min work on their own - then ask for choices - 1-2 of them. Ask why they selected those items as their primary and secondary factors.] - -Now let's say that I needed to traverse your hierarchy of factors to determine all of the rooms that I need to examine to [refinish all of the wood floors | refresh all of the plumbing | paint in pink every room in which your cat spends more than 30% of its time | some other characteristic that wouldn't be obvious from the hierarchy presented by the teams]. How much would your room factor hierarchy system help or hinder the process of selecting rooms? - -> What would be the best way to organize the rooms to optimize for this situation? [open discussion] - -Would you make a different choice for your room factor hierarchy if you knew that you would need to accommodate several different reasons for selecting a group of rooms? - -> [5 min - open discussion - things to bring out in the discussion -> -> 1. you won't know all of the reasons that you need to select rooms -> 2. It probably won't be possible to optimize for every selection that you may need to make, but there may be a structure that works well for the most common selection needs -> 3. Optimizing for one situation may make other situations nearly impossible to accommodate using the same hierarchy -> 4. How difficult would it be to adjust the hierarchy later? How should you adjust the hierarchy that you created to make it more flexible to accommodate what you don't yet know?] - -Similar to the exercise that we just did in developing a factor hierarchy for the rooms in the house, in the next section we will talk about the most common ways to classify the parts of your organization to optimize grouping for the most common reasons for selecting a groups of people. diff --git a/_episodes/02-cous.md b/_episodes/02-cous.md index ef09e03..b282d7d 100644 --- a/_episodes/02-cous.md +++ b/_episodes/02-cous.md @@ -10,6 +10,26 @@ keypoints: - "List the key takeaways for the episode" --- +# 2. Collaborative Organization Units (COUs) + +"Collaborative Organizations Units" allow you to define an organizational structure within a CO. While many organizations have natural groups within them, the reason that you would divide your CO into COUs are because there are differences across your CO that necessitates different policies in one or more of the following: + +* How individuals join and/or leave the group +* There are different rules about how applications get provisioned or deprovisioned +* Who manages person membership and privileges in the group +* The information stored or used about members of the group + +If your collaboration–a single entity with common goals–has unique requirements among the different groups and/or departments regarding how participants will join those parts of your collaborations, then, you have a CO that contains COUs. If you have only one common set of policies that define how individuals are added or removed from the CO, then you do not have COU even though you may have groups for simple access control. + +When you have COUs, they may represent recognized groups of collaborators like departments, divisions, projects; or they may be related to the privileges that those in the group may have, for example, alumni or parents. + +COUs are a structural object within Registry, meaning they can be configured, and that they are used internally for a variety of purposes. The primary purpose of a COU, however, is to allow for delegation of person management operations. [COU Administrators](https://spaces.at.internet2.edu/display/COmanage/Registry+Administrators) can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU). + +If COUs are defined, they can be flat (no hierarchy, all are at the same level), or a COU can have a parent COU (in which case a hierarchy is implied). + +> A COU relationship to a CO is similar to the way that LDAP OUs have a relationship within an O. + + # CO Person Role Status As with the :gear: `CO Person` object, each :gear: `CO Person Role` object @@ -42,4 +62,49 @@ The status of a CO Person is generally calculated from the status of the CO Pers 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 based on their status, as indicated in the table, below. \ No newline at end of file +CO Person and Person Role Records are passed to Provisioners based on their status, as indicated in the table, below. + +# Administrator Roles + +COmanage Registry defines three types of administrators. + +## Unit (COU) Administrators + +Collaboration Administrators with sophisticated administrative requirements may optionally define Unit Administrators. Unit Administrators have limited privileges within the CO, generally related to the ability to enroll and manage populations within the CO Unit (COU). + +Unit Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the _CO:COU:COU-Name:admins_ group (v2.0.0 and later) or _admin:COU-Name_ group (prior to v2.0.0) within the CO. + +COU Administrators can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU). + + +--- + +< TO BE UPDATED > + +# Terminology & resources + +## COmanage Objects + +OBJECT | DESCRIPTION +------ | ----------- +`CO Person` :gear: | the representation of a person in COmanage +`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear: + +## Worksheets + +WORKSHEET | DESCRIPTION +--------- | ----------- +[Modeling Organization :memo:](/files/handouts/CO310-ModelingOrgs.pdf) | Planning sheet used in this lesson for understanding how the parts of the COmanage Organization fit together. +[CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance. + +## Slides + +To be included + +--- + +NEXT SECTION: [2. The COU](/_episodes/02-cous.md) + +LESSON OVERVIEW: [CO320 - Modeling Your Organization in COmanage](../index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) diff --git a/_episodes/02-old-generalFactors.md b/_episodes/02-old-generalFactors.md deleted file mode 100644 index 83aa2d6..0000000 --- a/_episodes/02-old-generalFactors.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: "Understanding the factors that may affect your modeling" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -Review in broad strokes the factors that may affect how you model your organization, project or collaboration. Explore some real-world examples. - -## How are COs modeled in COmanage? - -COmanage is a multi-tenet tool. This means that for each installation, one or more top-level groups can be expressed. These groups are called Collaborative Organizations or COs. Individuals are added to these fundamental groups (COs), but once there, the individuals can be included in multiple sub groups of the CO, called Collaboration Organization Units (or COUs.) - -As a collaboration grows in size, it may be useful to create various structures to allow for delegation of person management operations and representation of organizational hierarchy. COmanage Registry supports this through the concept of CO Units, or COUs. As of Registry v3.1.0, CO Departments are also supported. - -### The COs - - The term “Collaborative Organization” or CO to refer to any formal or informal group of individuals that work collaboratively in a digital setting. They have a goal of a shared infrastructure that supports their collaborations so that the traditional limitations of localized applications may be overcome. Some traits of these COs include: - - * These individuals use a common workflow for adding collaborators. - * They share common policies for vetting the identities of collaborators. - * These COs may include individuals in a single organization, or individuals may be in multiple organizations, geographically different regions, or even work independently. - -COs can support one our more Collaborative Organization Units (COUs). - -### COUs - -"Collaborative Organizations Units" allow you to define an organizational structure within a CO. While many organizations have natural groups within them, the reason that you would divide your CO into COUs are because there are differences across your CO that necessitates different policies in one or more of the following: - -* How individuals join and/or leave the group -* There are different rules about how applications get provisioned or deprovisioned -* Who manages person membership and privileges in the group -* The information stored or used about members of the group - -If your collaboration–a single entity with common goals–has unique requirements among the different groups and/or departments regarding how participants will join those parts of your collaborations, then, you have a CO that contains COUs. If you have only one common set of policies that define how individuals are added or removed from the CO, then you do not have COU even though you may have groups for simple access control. - -When you have COUs, they may represent recognized groups of collaborators like departments, divisions, projects; or they may be related to the privileges that those in the group may have, for example, alumni or parents. - -COUs are a structural object within Registry, meaning they can be configured, and that they are used internally for a variety of purposes. The primary purpose of a COU, however, is to allow for delegation of person management operations. [COU Administrators](https://spaces.at.internet2.edu/display/COmanage/Registry+Administrators) can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU). - -If COUs are defined, they can be flat (no hierarchy, all are at the same level), or a COU can have a parent COU (in which case a hierarchy is implied). - -> A COU relationship to a CO is similar to the way that LDAP OUs have a relationship within an O. - -### 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. - -### CO Groups - -There is also a structure called CO Groups - these are explored in depth in Lesson 306. - -#### COUs vs CO Groups - -The major differences between COUs and CO Groups 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). - - -#### An example - LIGO - -LIGO is a virtual organization with a concrete goal (discovering gravitational waves) and specific large equipment (the detectors) to help reach that goal. LIGO, however, is not a uniform, flat organization. Within LIGO, there are several smaller organizations. These smaller organizations have specific needs regarding how new people join in their groups, and yet, these smaller organizations all have something in common - the parent organization of LIGO, where access to the equipment and the data is controlled, where agreements may be signed with new organizations wanting to be a part of (or a partner of) LIGO. - -Here, LIGO is represented as a CO, and the smaller organizations are represented by COUs. - -## What are the most common factors for modeling the groups of individuals in your organization - -There are many ways to group people in your organization. For tools like Membership Management Services, there are several common factors to consider: - -1. Where does the data about the person come from - also known as "Systems of Record" -2. What are the conditions under which individuals gain or loose access to resources or services -3. Logical groups like departments, projects, or teams - - -## Consideration factors - -**RESOURCE**: [COmanage Planning: Modeling your collaborative organization](/files/handouts/COmanage Planning_ Modeling your collaborative organization.pdf) - -Collaborations come in all sizes and levels of complexity. From complex virtual organizations that span multiple countries, to informal groups within a collaboration at a single campus, COmanage provides enough flexibility to support most types of collaborations. - -Depending on the size and complexity of your virtual organization, you need to consider how people should join the collaboration (e.g., the enrollment process), what applications they might need to accomplish their goals, and how they should be removed or expired at the end of their participation in the VO. The COmanage team has put together the resource above with questions that target several of the possible layers within a collaboration. While not all questions apply, by going through this assessment, you will learn more about your own processes and decide what is important for the platform. - -In modeling your collaborative organization, \ No newline at end of file diff --git a/_episodes/03-departments.md b/_episodes/03-departments.md index 81af82f..8d210d8 100644 --- a/_episodes/03-departments.md +++ b/_episodes/03-departments.md @@ -10,7 +10,7 @@ keypoints: - "List the key takeaways for the episode" --- -## 3. About CO Departments +# 3. Collaborative Organization (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: @@ -21,4 +21,37 @@ While there may typically be a one-to-one relationship between CO Departments an 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. \ No newline at end of file +CO Departments are specifically intended to be used with [Registry Services](https://spaces.at.internet2.edu/display/COmanage/Registry+Services) and the Service Portal. + + +--- + +< TO BE UPDATED > + +# Terminology & resources + +## COmanage Objects + +OBJECT | DESCRIPTION +------ | ----------- +`CO Person` :gear: | the representation of a person in COmanage +`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear: + +## Worksheets + +WORKSHEET | DESCRIPTION +--------- | ----------- +[Modeling Organization :memo:](/files/handouts/CO310-ModelingOrgs.pdf) | Planning sheet used in this lesson for understanding how the parts of the COmanage Organization fit together. +[CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance. + +## Slides + +To be included + +--- + +NEXT SECTION: [2. The COU](/_episodes/02-cous.md) + +LESSON OVERVIEW: [CO320 - Modeling Your Organization in COmanage](../index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) diff --git a/_episodes/03-old-yourFactors.md b/_episodes/03-old-yourFactors.md deleted file mode 100644 index 26a88d3..0000000 --- a/_episodes/03-old-yourFactors.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Considering the factors for your situation" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -Using the modeling worksheet you will consider your own organization, project or collaboration and the factors that may affect its model within COmanage. - -## Episode section - -... and content \ No newline at end of file diff --git a/_episodes/04-groups.md b/_episodes/04-groups.md index 90b58ce..35be950 100644 --- a/_episodes/04-groups.md +++ b/_episodes/04-groups.md @@ -14,11 +14,9 @@ keypoints: 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 +The major differences between COUs and CO Groups 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. @@ -50,124 +48,11 @@ CO Groups provide basic group functionality enabling actions to be applied to al 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: - -* 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. # CO Email lists @@ -216,55 +101,37 @@ If at least one CO Service is configured with Unauthenticated User visibility, t > 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) - ----- - -# Administrator Roles -COmanage Registry defines three types of administrators. - -## Platform (CMP) Administrators _(Also called Registry Admin in the documentation)_ +--- -Platform Administrators are effectively super users, with the ability to perform almost all operations on the platform. (Platform Administrators cannot execute enrollment flows for COs unless authorized by the enrollment flow.) +< TO BE UPDATED > -Platform Administrators are configured by [adding the appropriate Organizational Identity](https://spaces.at.internet2.edu/display/COmanage/Default+Registry+Enrollment) to the COmanage CO, and then adding the corresponding person to the CO:admins group (v2.0.0 and later) or admin group (prior to v2.0.0) within the COmanage CO. +# Terminology & resources -The first user added as part of the [Registry Setup Script](https://spaces.at.internet2.edu/display/COmanage/Registry+Installation+-+Registry+Setup+Script) is automatically configured to be a Platform Administrator. +## COmanage Objects -## Collaboration (CO) Administrators +OBJECT | DESCRIPTION +------ | ----------- +`CO Person` :gear: | the representation of a person in COmanage +`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear: -Collaboration Administrators are super users _within a CO_. Collaboration Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the CO:admins group (v2.0.0 and later) or admin group (prior to v2.0.0) within the CO. +## Worksheets -CO Administrators can manage any CO Group within their CO. +WORKSHEET | DESCRIPTION +--------- | ----------- +[Modeling Organization :memo:](/files/handouts/CO310-ModelingOrgs.pdf) | Planning sheet used in this lesson for understanding how the parts of the COmanage Organization fit together. +[CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance. -## Unit (COU) Administrators +## Slides -Collaboration Administrators with sophisticated administrative requirements may optionally define Unit Administrators. Unit Administrators have limited privileges within the CO, generally related to the ability to enroll and manage populations within the CO Unit (COU). +To be included -Unit Administrators are configured by adding the appropriate Organizational Identity to the CO (if not already done), and then adding the corresponding person to the _CO:COU:COU-Name:admins_ group (v2.0.0 and later) or _admin:COU-Name_ group (prior to v2.0.0) within the CO. +--- -COU Administrators can be defined for each COU, giving them the ability to perform lifecycle management operations on the CO People who have CO Person Roles associated with the COU that they manage (or any child COUs of that COU). +NEXT SECTION: [2. The COU](/_episodes/02-cous.md) -## System Administrators +LESSON OVERVIEW: [CO320 - Modeling Your Organization in COmanage](../index.md) -System Administrators have privileges that enable them to maintain the COmanage application. These capabilities include the ability to provision cluster resources (for example, hardware, virtual machines, etc), Register and maintain IP Addresses, administer application upgrades, manage and conduct operating system upgrades and conduct backups. +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) - -## 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) | | \ No newline at end of file diff --git a/_episodes/04-old-yourModel.md b/_episodes/04-old-yourModel.md deleted file mode 100644 index 283c771..0000000 --- a/_episodes/04-old-yourModel.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "Picking a model" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -Working collaboratively with others in the class, choose a model that you think would work for your situation, and then implement it in COmanage. - -# PICK YOUR MODEL - -The steps to do this - -Use the [CO Worksheet](/files/handouts/COmanage Planning_ CO_Worksheet.pdf) to plan out your CO. - -Work in pairs to discuss the choices that you made. Make adjustments in your plan as needed. - -# Then IMPLEMENT IT... - -## Create a CO - -![Interactive system activity](../assets/img/hands-on-keyboard.png) - -**REQUIRED ROLE**: Platform Administrator - -1. Sign into COmanage as a Platform Administrator. Once you sign in you will see a list of available collaborations. -2. Since you want to create a new CO, from the menu, select Platform > COs to display the CO Management Overview List. - -![Navigate to the CO Management Overview List](../fig/CO301-04_COMgmtList_2019-09-06.png) - -3. Click the "Add CO" link above the table on the right side to add a new CO. - -![CO management Overview list](../fig/CO301-04_COMgmtOverviewList_2019-09-06.png) - -4. Fill in the fields: - a. **The name of your CO.** This name will be displayed on lists and elsewhere. It is a good idea for this name to be descriptive, but relatively short. - b. **Description.** Write a short description of your CO. This description will be helpful for those who may not be familiar with your CO's name. - c. **Status.** There are three choices for the status: - * Active - you will select this one. Your CO will be immediately active upon its creation. - * Suspended - Useful if you do not want your CO to be active. - * Template - Useful if you want to create several COs based on the configuration from this one. - -## Configure your CO - -![Interactive system activity](../assets/img/hands-on-keyboard.png) - -### Settings - -The settings section for your CO enables you to configure the CO behavior. While there are several settings, we will only discuss the most common ones today. More details can be found on the [documentation page in the COmanage wiki](https://spaces.at.internet2.edu/display/COmanage/How+to+Configure+a+CO). - -**REQUIRED ROLE**: Platform Administrator | Collaboration (CO)Administrator - - -1. From the Collaborations list page, click on the name of the Collaboration that you want to configure. -2. In the CO menu, click on the "Configuration" link to see the list of customizations that you can make. Click on the first link, "CO Settings" to adjust the settings. - -![Navigate to COSettings Configuration > CO Settings](../assets/img/CO301-04_COSettings_2019-09-06.png) - -3. Using the values that you put in your [CO Worksheet](/files/handouts/COmanage Planning_ CO_Worksheet.pdf), adjust the settings for your CO. -4. Click the `SAVE` button to save your work. diff --git a/_episodes/05-old-generalCous.md b/_episodes/05-old-generalCous.md deleted file mode 100644 index 69d3629..0000000 --- a/_episodes/05-old-generalCous.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: "Modeling within COmanage" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -Learn about Collaboration Organization Units (COUs), and how they are used to express a model in COmanage. - -## Episode section - -... and content - diff --git a/_episodes/05-yourOrg.md b/_episodes/05-yourOrg.md new file mode 100644 index 0000000..743ffb3 --- /dev/null +++ b/_episodes/05-yourOrg.md @@ -0,0 +1,209 @@ +--- +title: "Setting up your organization" +teaching: 20 +exercises: 0 +questions: +- "Question here" +objectives: +- "List the objectives" +keypoints: +- "List the key takeaways for the episode" +--- + +# 5. Setting up your organization + +# Then IMPLEMENT IT... + +## Create a CO + +![Interactive system activity](../assets/img/hands-on-keyboard.png) + +**REQUIRED ROLE**: Platform Administrator + +1. Sign into COmanage as a Platform Administrator. Once you sign in you will see a list of available collaborations. +2. Since you want to create a new CO, from the menu, select Platform > COs to display the CO Management Overview List. + +![Navigate to the CO Management Overview List](../fig/CO301-04_COMgmtList_2019-09-06.png) + +3. Click the "Add CO" link above the table on the right side to add a new CO. + +![CO management Overview list](../fig/CO301-04_COMgmtOverviewList_2019-09-06.png) + +4. Fill in the fields: + a. **The name of your CO.** This name will be displayed on lists and elsewhere. It is a good idea for this name to be descriptive, but relatively short. + b. **Description.** Write a short description of your CO. This description will be helpful for those who may not be familiar with your CO's name. + c. **Status.** There are three choices for the status: + * Active - you will select this one. Your CO will be immediately active upon its creation. + * Suspended - Useful if you do not want your CO to be active. + * Template - Useful if you want to create several COs based on the configuration from this one. + +## Configure your CO + +![Interactive system activity](../assets/img/hands-on-keyboard.png) + +### Settings + +The settings section for your CO enables you to configure the CO behavior. While there are several settings, we will only discuss the most common ones today. More details can be found on the [documentation page in the COmanage wiki](https://spaces.at.internet2.edu/display/COmanage/How+to+Configure+a+CO). + +**REQUIRED ROLE**: Platform Administrator | Collaboration (CO)Administrator + + +1. From the Collaborations list page, click on the name of the Collaboration that you want to configure. +2. In the CO menu, click on the "Configuration" link to see the list of customizations that you can make. Click on the first link, "CO Settings" to adjust the settings. + +![Navigate to COSettings Configuration > CO Settings](../assets/img/CO301-04_COSettings_2019-09-06.png) + +3. Using the values that you put in your [CO Worksheet](/files/handouts/COmanage Planning_ CO_Worksheet.pdf), adjust the settings for your CO. +4. Click the `SAVE` button to save your work. + +# 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: + +* 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. + + +--- + +< TO BE UPDATED > + +# Terminology & resources + +## COmanage Objects + +OBJECT | DESCRIPTION +------ | ----------- +`CO Person` :gear: | the representation of a person in COmanage +`CO Group` :gear: | a specific COmanage organizational structure for representing certain collections of `CO Persons` :gear: + +## Worksheets + +WORKSHEET | DESCRIPTION +--------- | ----------- +[Modeling Organization :memo:](/files/handouts/CO310-ModelingOrgs.pdf) | Planning sheet used in this lesson for understanding how the parts of the COmanage Organization fit together. +[CO Planning Worksheet :memo:](/files/handouts/CO320-01_COPlanningWorksheet.pdf) | Planning worksheet for creating your CO(s). Contains all of the configuration sections at a glance. + +## Slides + +To be included + +--- + +NEXT SECTION: [2. The COU](/_episodes/02-cous.md) + +LESSON OVERVIEW: [CO320 - Modeling Your Organization in COmanage](../index.md) + +WORKSHOP OVERVIEW: [COmanage Workshop: Managing Identities & Collaborations](https://github.internet2.edu/lpaglione/COmg-trainingOverview/blob/master/README.md) diff --git a/_episodes/06-old-yourCous.md b/_episodes/06-old-yourCous.md deleted file mode 100644 index f82e832..0000000 --- a/_episodes/06-old-yourCous.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Express your model with COUs" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -Using the model that you have picked, express it in COmanage. - -## Episode section - -... and content \ No newline at end of file diff --git a/_episodes/07-old-changesHappen.md b/_episodes/07-old-changesHappen.md deleted file mode 100644 index 3942735..0000000 --- a/_episodes/07-old-changesHappen.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "Making changes" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -It's impossible to anticipate all needs. How do you adjust your model when necessary? - -## Episode section - -... and content \ No newline at end of file diff --git a/_episodes/08-old-advanced.md b/_episodes/08-old-advanced.md deleted file mode 100644 index 34644eb..0000000 --- a/_episodes/08-old-advanced.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "Advanced Topics" -teaching: 10 -exercises: 0 -questions: -- "Question here" -objectives: -- "List the objectives" -keypoints: -- "List the key takeaways for the episode" ---- - -During this section we will review advanced topics of interest to the class. Some examples include: - -* - -## Episode section - -... and content - -COUs can be hierarchical; COUs can be directly a part of the CO, or can be a sub-part of another COU. \ No newline at end of file diff --git a/files/handouts/CO320-01_COPlanningWorksheet.pdf b/files/handouts/CO320-01_COPlanningWorksheet.pdf new file mode 100644 index 0000000..33a9bd4 Binary files /dev/null and b/files/handouts/CO320-01_COPlanningWorksheet.pdf differ