Child pages
  • Finer Grained Document-Level Matrix Permissions
Skip to end of metadata
Go to start of metadata
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

Title:

Finer Grained Document-Level Matrix Permissions

Jira Number:

SAK-16505

Related Jira Numbers:

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
Date: Reviewed August 3, 2009 (branch & demo pending)


Part 1: Functional Description


Finer Grained Document-Level Matrix Permissions (1)

Summary (1)

The proposed functionality will provide shared control at the document level to a group of specific users. Moreover, the functionality of adding a private comment is enabled which is visible only for the owner of the document and the creator of the feedback.

Rationale (1)

The proposed enhancement is a requirement to enable interns to reflect on their hospital training, the difficulties they face in their trainings. They have to fill out forms prepared by a tutor where they can report their reflection on their trainings. The forms are organized in a matrix where columns are trainings and rows are competencies. The proposed enhancement is to allow reviewers to review the forms at the cell level with reviewing permissions at the document level. Currently, the permission to review a form was only at the cell level which means a reviewer had access to all forms of a cell or to none. Because these reflections can involve other residents and staff members' interaction, the resident wants to ensure that only a restricted group of people can review their reflection. In addition, the reviewers are chosen by the intern who can add new participants or remove the reviewing rights at any time. The proposed enhancement ensures confidentiality at the document level in a cell matrix and is a step toward more collaborative work between peers.

An appendant feature of the proposed enhancement is the new review type "private feedback". Currently, reviewers can give feedbacks to documents which are visible for everyone who has access to the cell of the document. The new type of private comments is only viewable by the writer of the feedback and the owner of the document. Using private feedbacks, reviewers feel freer to add constructive criticism which again enriches the collaborative work.

Origin (1)

The origin is the Faculty of Medicine at Université de Montréal. The department wishes to foster collaborative learning by sharing and exchanging reflections with other colleagues.

User Stories (1)

Actors and Stakeholders

  • Residents: medicine residents, interns.
  • Tutors: a person who is a senior resident or a doctor.

Stories

  • Invite a group of individuals to review a reflection. As a resident, I want to invite a restricted group of people review my reflection. Only these people will have the right to see that the document exists, to read the document and to comment it.
  • Read and comment a reflection. As an invited person, I want to see that the document exists and I want to read the reflection (the content of the reflection), and review the reflection.
  • Read a reviewer's private comment. As a resident, I want to read the reviewer's feedback on my reflection. This comment is not visible for other reviewers and cannot influence them on their feedbacks.

Functional Details (may be added after community demo) (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.

Interaction and Implications (1)

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
contains forms or create forms in cell.

2. Click on button next to form for
selecting reviewers for this document.

3. Change reviewing permissions by
addingor removing users to/from the
list of selected users. Selected users
receive an invitation via e-mail.



4. Result: User "resident2" has access
to form "Reflection on collaboration"
and can review it.

5. Result: User "resident3" has no access
to form "Reflection on collaboration"
and cannot see that it exists.

Read and comment a reflection.

 

 



1. See accessible reflections and click
on button to add a private feedback.

2. Result: Creator can review his/her
given private feedback.



3. Result: Owner of document can
review private feedback of reviewer.

4. Result: User "resident3" has no
access to private feedback created
by user "resident2".

Community Acceptance (4)

Elements of this enhancement have been raised on sakai-dev@collab.sakaiproject.org and portfolio@collab.sakaiproject.org. Also, during the meeting of Monday 2009-02-03 11 am, we discussed details and that seem to raise interests among participants.



Part 2 of the Proposal for Enhancement Template: The Specification
The specification should be filled out once the feature is clearly defined.


Specification Template (5)

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:

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.

  • No labels

5 Comments

  1. Comments from the August 3rd OSP conference call review:

    • A reviewer can view a form/reflection from another owner in the reviewer's matrix cell. This is a change in current paradigm of what goes in matrix cells. We wondered if you had considered using a different approach (such as a synoptic tool that might show forms needing peer review).
    • There was also some concern about how reviewers would find the forms needing review (would the email notification mention the matrix cell and contain a link?)
    • Will the selection of users to be reviewers use existing review selection helper tool? Will it allow users from only the worksite, or the entire sakai instance (the latter being a usability concern for institutions with thousands of users)

    Overall there were no objections to the functionality (as long as made optional), and the next step would be to respond to any comments on this page, and create a subversion branch so the community can try it out.

    1. Unknown User (boufaden)

      Hi Beth,

      • Actually a reviewer who was granted access  can view a form/reflection from another owner not in the reviewer's matrix cell but in the owner's matrix. The reviewer will see a new tab (displaying the reflection's owner matrix) in his site. The new tab allows the reviewer to access the reflection's owner matrix and see all the form/reflection he was granted access to. then by clicking on a reflection, the reviewer can send a feedback. So each additional tab gives access to a student reflections of corse given the reviewer was granted access to thoses reflections.  So in that way I don't think there is any change in the paradigm. It'is only a matter of making reviews at a finer level and making the access to the reflections easier to reviewers.
      • Actually, there is an email notification for each reviewer who was asked to leave a feedback. For now we have a link to the site, but not to the cell yet. These are among the enhancements we will work on.
      • For now the selection helper tool allows users from the entire sakai instance. I agree that this is not the best way to handle the selection of users. We are already thinking about giving the ability to create groups to make the selection process easier and be able to handle large user communities. 
    1. I share Beth's concerns about the paradigm shift.  One's personal copy of the matrix was never intended to contain evidence submitted by other users.  If students share forms or  dcouments in their matrix with peers (other participants in the site), the evidence area of each users matrix would contain work by multiple users, which would be confusing to the matrix owner and reviewers.  I agree with Beth that a synoptic tool would be preferable for reviewing forms that have been shared.  Another approach might be to allow the reviewer to access the  forms in the usual way (via the participant's cell), but hide items that haven't been explicitly shared with the reviewer.
    2. Will this feature also apply to attachments in the evidence area of the cell?
    3. The IU enhancements slated for 2.7 already provide the following features:
      1. ability to invite a reviewer to view the contents of a cell.  Invitations can be sent to any user with a Sakai account.
      2. ability to restrict access to feedback so that it can only be read by the matrix owner and the reviewer who created the feedback.
      3. ability to restrict reviewer access to a single cell.  The CRIM implementation provides even greater granularity, but I wonder whether the same result couldn't be achieved by placing only one form in each cell.  This may not be practical if the matrix already has a fair number of rows and columns.
    4. We probably would not want to turn this functionality on at IU unless item #1 above is addressed and even then, only in specific cases.  Beth's comments refers to making the feature optional.   Will this be a global setting or implemented on a cases by case basis, perhaps via permissions or a flag in matrix properties? If item #1 one is addressed, it would be nice to be able to turn the feature on or off on a case by case basis.  If it won't be addressed in the first iteration, we'd prefer to be able to turn it off globally.
    1. Unknown User (boufaden)

      1. Sorry for the delay, but as I explained in my first comment,  one's personal copy of the matrix doesn't contain evidence submitted by other users. It is displayed in another matrix ina different tab added temporarly (as long as he is granted the right to access that matrix) to the reviewer site. So the fact that we add a new tab and a new matrix act as a synoptic tool.
      2. No it is not applied to attachments in the evidence area of a cell. Our main concern was to give the ability to add feedbacks and comments to the different form/reflection in a cell.
      3. Yes, all these capabilities are at the cell level and apply to all the forms at once in a cell. What we proposed goes beyond the cell level and applies to the form level in a cell.
  2. The following comments are compiled from the September 28 demo of this functionality:

    1. We'd like to verify that cell-page attachments are subject to the same access restrictions as forms attached to a cell.

    2. Currently the finer-grained matrix permissions are based on a sakai installation with one user per matrix site. We'd like to verify this feature will work when there is more than one user in a matrix site.

    3. The reviewer selection user interface could be problematic if there are thousands of users -- there was discussion of replacing the user browse functionality with a user "suggestion" functionality.

    4. We'd like to have the ability to completely disable this functionality (and also optionally enable/disable at the matrix level, if possible)

    Thanks for the demo!