Child pages
  • Permissions, Workflow, and Publishing
Skip to end of metadata
Go to start of metadata

This page is a landing for concerns and work around changes to the permission structure, workflow support, and publishing techniques available in OSP.


  • Permissions - this work refers to the actual roles and actions in the system, along with the permissions that enable a user in a role to perform an action.
  • Workflow - this work entails defining and supporting actions in particular sequences, such as guided learning experiences.
  • Publishing - this work refers to understanding the actions and workflows specific to a participant publishing work to reviewers and evaluators for feedback or presentation.

Institutional Requirements

University of Michigan

Michigan has identifed that there are some very specific scenarios that must be supported locally. It is highly unlikely that they are isolated cases, so are presented here for discussion. This list is divided into functional and usability needs. These will be consolidated into a set of feature specifications for implementation and formal discussion. These feature specifications will be linked here rather than the current lists. U-M is committed to implementing these features to fit the specific local needs while working closely with the community to avoid collisions or rework.

Functionality Requirements

Multiple Evaluator Types per Cell

Matrix managers must be able to establish different types of Evaluators within a site. It must be possible to differentiate between these Evaluator types with respect to permissions in the site and for specific Matrices/Wizards.

Multiple Evaluation Forms per Cell

Matrix managers must be able to attach multiple evaluation devices to a single cell. Each form should allow permissions to be granted such that different types of Evaluators may complete exclusive devices.

Arbitrary Cell Publishing

Participants of a Matrix/Wizard experience must be able to solicit Feedback or Evaluation from arbitrary users on the contents of a cell. __(NOTE: This requirement needs more detail about whether feedback from users outside of the site should be visible to the Matrix reviewers, etc. Use case is forthcoming.)

Form Customization Permissions

When a Form is attached to a Cell, users must be able to be granted the permission to customize the instructions without the "Manage Matrices" permission. The instructions must be able to be overridden for that cell, beginning with a copy of the Form's default instructions.

Per-Cell Evaluation Workflow Options

A Cell must be able to be configured so that some Evaluator Types may not change cell status after completing an Evaluation.

  1. Guiding users (instructor/evaluator) should able to lock and "hand off" components to users who will take further action before returning an item to a student. (Per-item workflow phases)*
  2. Artifacts linked or submitted through a portion (cell) of the portfolio must be available to the users that may view that portion (cell) (SAK-7464)**

* Potential large-scale workflow implications
** Being implemented for 2.5 release as a bugfix

Usability Requirements

NOTE: These usability requirements necessarily overlap with the notion of "Individualized Perspectives" or "Personalized Views", where the assumption here is that each can reach a view that contains relevant items from across sites and tools. These particular requirements are specific to publishing or viewing items needing interaction and may be moved to the larger dashboard discussion at some point.

  1. Users must be able to filter a view to only those items that they may interact with
    1. Students must be able to filter to just those cells that are available
    2. Instructors must be able to filter to just completed cells that are pending evaluation
  2. Users must be able to filter or sort by recency of request or status change on a list of items
  3. Users must be able to filter a view to those items where another user has requested interaction (feedback/evaluation)
  4. Users must have the ability to opt into email notification for certain events (cells becoming available, being submitted, etc.)
  5. Notification opt-in should provide useful batch operations such as enabling notification for all Matrices, Matrices within a specific site, a group of cells, new requests for feedback, all new pending evaluations, etc.
  6. Batch operations should be better supported (changing a group of cells to available)
  • No labels