Use Case 08: Manage Groups/Communities

From Earth Science Information Partners (ESIP)
Revision as of 13:45, January 30, 2006 by Kbene (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Use Case Template

Use Case EIE08: Manage Working Group (Communities)

for

ESIP Earth Information Exchange

Revision History

Name

Date

Reason For Changes

Version

Karl Benedict

12/13/05

Document created

1

1.Use Case Identification

1.1.Use Case Number

EIE08

1.2.Use Case Name

2.Use Case Definition

Support for thematically oriented groups within the portal is important for providing a high level organizational structure to the content and presentation of the materials provided by the portal. This use case documents the capability of portal administrators (Operators) to create topical groups on behalf of users that propose the creation of such communities, and the capability for users (acting in the role of community manager) to manage those communities.

2.1.Actors

Users (role: community manager)

Operators

2.2.Preconditions

  1. User’s identity has been authenticated.

2.3.Postconditions

  1. A new community has been created, or

  2. An existing community has been modified.

2.4.Normal Flow

  1. User is authenticated as a registered user

  2. User accesses a form to request the creation of a new community

  3. User completes the form and submits it for review by the portal administrator.

  4. Portal administrator is authenticated as a registered user and portal administrator

  5. Portal administrator reviews the request

  6. Portal administrator accesses a community creation form.

  7. Portal administrator completes the community creation form and submits it to the system. Information included in the form includes: id of designated community manager, name and description of community, status of community.

  8. The community is created as a result of the submission of the community creation form.

2.5.Alternative Flows

Modification of existing community

  1. User is authenticated as a registered user and community manager (for a specified community(ies).

  2. User enters a specific community area

  3. User is presented with an option to manage the community through a link in the community interface.

  4. User selects the community management page.

  5. User provides the needed community management information through the provided management form: i.e. Add datasets, granules, services; modify community area content, manage community membership.

  6. User submits form to portal

  7. Community area of portal is updated with community area modifications.

Deletion of community at request of community managers

  1. User is authenticated as a registered user and community manager (for a specified community(ies).

  2. User enters a specific community area

  3. User is presented with an option to manage the community through a link in the community interface.

  4. User selects the community management page.

  5. User requests that the community be deleted through a form field on the management page.

  6. Portal administrator is authenticated as a portal user and administrator.

  7. Portal administrator reviews request for community deletion.

  8. Portal administrator accesses community management page.

  9. Portal administrator confirms deletion of community through completion of the community deletion form and submission of the form.

  10. Community is deleted from the portal.

Deletion of community by portal administrator.

  1. Portal administrator is authenticated as a portal user and administrator.

  2. Portal administrator accesses community management page.

  3. Portal initiates and confirms the deletion of community through completion of the community deletion form and submission of the form.

  4. Community is deleted from the portal.

2.6.Exceptions

2.7.Extension Points

None

2.8.Priority

High.

2.9.Frequency of Use

2.10.Business Rules

2.11.Special Requirements

None

2.12.Assumptions

None

2.13.Notes and Issues

Degree of delegated authority provided to community managers (as opposed to portal administrators) needs to be clearly defined. Being able to delegate all day-to-day management authority to community managers would be highly desireable, but what additional authority should be vested in them?

Community status conditions should be defined to facilitate management: i.e. Active, inactive, public, private, deleted. Use of these status flags will streamline the 'publication' process for community areas.