| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
Title: | Finer Grained Document-Level Matrix Permissions |
|---|---|
Jira Number: | tbd SAK-16505 |
Related Jira Numbers: | SAK-16505 n/a |
Component(s): | OSP Matrix |
Author: | Narjes Boufaden (CRIM), Jean-Marc Heneman (CRIM), Katharina Bauer-Öppinger (CRIM) |
Date: | February 4, 2009 |
Demo Status and Date(s): | Status: Suggested |
| Table of Contents |
|---|
...
This template is the vehicle for complying with the OSP Procedure for Feature Requests. Each element of the template is keyed to the step that the element fulfills, in whole or in part. For example, a (1) in the heading indicates that this portion of the template must be filled out in order to complete step 1 of the proposal approval process. The Proposal for Enhancement page you create in Confluence based on this template will provide a locus for community discussion of the enhancement. A primary goal of this process is to capture institutional memory about what decisions were made during the design phase and why.
The Proposal for Enhancements template has two parts, the Functional Description and the Technical Specification. The expectation is that the template will be fleshed out over time as plans for the enhancement develop through community discussion.
...
Part 1: The Functional Description The Functional Description should be created before the enhancement is first proposed, usually by domain experts such as instructional designers, educators, or project leads. As much as possible, it should paint a picture of what the enhancement is and what it will allow the user to accomplish. Focus should be on functionality rather than implementation. While the Summary, Rationale, Origin, and User Stories are required before the proposal is presented to the community, diagrams, mockups, and the "Functional Details" and "Interactions and Implications" sections may be added later as the proposal matures.
Part 2: The Technical Specification
The second part of the proposal, the Specification, should be filled out once the feature is clearly defined but before coding begins. While the first part of the proposal should usually be filled out by domain experts, the specification would normally be written by a developer or other technical person.
Please remove these instructions from your document.
Part 1: Functional Description
...
Finer Grained Document-Level Matrix Permissions (1)
...
The resident who wishes to invite individuals will select them from a list of possible individuals. For now, the list of possible individuals is generated from the list of the site users. An enhancement for this configuration would be to define groups of users and allow users not in the site to be part of the groups. The invited people will only see documents they are granted to review and can add private comments which are only viewable for the resident.
...
A participant can grant reviewing permissions by document (filled form) in a matrix cell. A reviewer can review only the forms that were granted by the owner of the forms. Reviews are not viewable by everyone with access to the matrix cell but only by the reviewer and the owner of the document.
Diagrams and Mockups (3)
...
)
...
Invite a group of individuals to review a reflection.
|
|
|
|---|---|---|
| | |
1. Enter cell of matrix that already | 2. Click on button next to form for | 3. Change reviewing permissions by |
| | |
4. Result: User "resident2" has access | 5. Result: User "resident3" has no access |
...
Specification Template (5)
Behavior
Describe each specific behavior of the feature in the present tense as if the feature were implemented perfectly. Use precise, objective language to describe ideal behaviors against which actual behaviors can be evaluated.
In the case of conditions and behaviors that must be evaluated independently, they should be presented in a two-column table as below.
Conditions | Behavior |
|---|---|
(Short description of mutually exclusive condition #1) | (Objective, verifiable behavior in response to condition #1) |
(Short description of mutually exclusive condition #2) | (Objective, verifiable behavior in response to condition #2) |
When there are workflow behaviors (steps) that must be evaluated in sequence, they should be identified with prerequisite conditions, behavior, and post-behavior conditions as below.
Workflow Steps
(Unique, short, representative name of the step) | |
|---|---|
Prerequisite Conditions or Step: | (Conditions or Step name) |
Behavior: | (Objective, verifiable behavior) Invitation of Users for Reviewing Reflection |
Prerequisite Conditions or Step: | Document (filled form) created in a matrix cell. |
Behavior: | By default no user (except owner of document) has reviewing permissions. Users of current site are shown in selector for document-level permissions. Selected user IDs are stored as a property (IDs are connected to a String) in resource of document. After confirmation of selected users, the invitation is sent via e-mail to the reviewers. |
Post-step Conditions or Next Step: | Document-Level Matrix Permissions |
Document-Level Matrix Permissions | |
|---|---|
Prerequisite Conditions or Step: | Resident invited users to review his/her reflection. Reviewers received an invitation via e-mail. Users' IDs are stored in resource of document. |
Behavior: | Before showing a document in a matrix cell, its resource property which includes IDs of permitted users is read. If current user ID is stored in resource of document, he/she can see the specific document. |
Post-step Conditions or Next Step: | Invited users can review document and add a comment. |
Addition of Private Feedback | |
|---|---|
Prerequisite Conditions or Step: | Invitation for reviewing reflection. User has access to document. |
Behavior: | User adds a private feedback by clicking on button next to document and using the same form as for adding a "normal" feedback. This feedback uses new review type "private feedback". |
Post-step Conditions or Next Step: ( | Access to private feedback. |
Access to Private Feedback |
|---|
Prerequisite Conditions or Step name) |
Interaction
List any entities or actors that are used or affected by this feature. Each should link to an entry in the OSP Terminology page.
Quality Metrics
Describe any non-functional requirements of the feature, such as usability, performance, or design. Provide objective and, where possible, quantitative measures against which actual implementations can be evaluated.
Assumptions
Provide any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.
Outstanding Issues
...
: | Invited reviewer added private feedback to a reflection. |
Behavior: | Before showing a review document in a matrix cell, type of review is checked for "private feedback". If document has type "private feedback", current user ID is compared with the creator ID of review and with the owner ID of document (filled form). Only those users are permitted to access a private feedback. |
Post-step Conditions or Next Step: | Reviewing process continues as previously implemented. |
Interaction
- Matrix Wizard: Access of wizard page forms modified for checking permitted user IDs with current user ID.
- Portfolio Review: New review type "private feedback" as well as comparison of review's creator ID or form's owner ID with current user ID added.
Quality Metrics
The ability of selecting reviewers for each document in a matrix cell gave more flexibility to the matrix. In the same screen, the user can add a form and select it for reviewing by individuals chosen by him.
Assumptions
n/a
Outstanding Issues
Following the recommendations of the SAKAI community, we will be refining the concept of private feedback at the document level by allowing groups of users to be defined and selected in the dialog box.