Reviewed Community Ideas for Future OSP Releases

Owned by Former user (Deleted)
Last updated: Dec 02, 2008Version comment
11 min read

Matrix/Owner Permissions (Kristol Hancock, IU)

Good morning! IU is currently working on some enhancements to the Reviewer and Evaluator workflow and in doing so, we've been thinking through the permissions in light of the enhancements we would like to make. In reviewing the permissions for the Matrices tool, I've come across a bit of a stumbling block and I have a solution that I would like to receive feedback on from the community. First, let me describe the issue.

I'm struggling with the fact that assigning the Create permission to a role enables users assigned to that role to also edit, delete, publish and export matrices owned by that user regardless of whether or not the role assigned to the user has the edit, delete, publish and/or export permissions. If we believe that keeping these permissions separate is the way to go, then I'd like to suggest that we change the edit, delete, publish and export permissions a bit to ensure that the permissions assigned to a role are explicit.

For those who are not entirely familiar with the way these permissions currently work, an explanation of each permission follows:

Create: Users assigned to a role with the 'Create' permission may create a new matrix and may create, edit, and delete links from this matrix to other activities. These same users may edit, delete, publish and export a matrix that was created by the user.
Edit: Users assigned to a role with the 'Edit' permission may edit the structure, guidance, and forms of an existing matrix that may or may not have been created by this user.
Delete: Users assigned to a role with the 'Delete' permission may permanently remove an existing published or unpublished matrix that may or may not have been created by this user.
Publish: Users assigned to a role with the 'Publish' permission may make a new or imported matrix, that may or may not have been created by this user, available for use by participants, evaluators, and/or reviewers.
Export: Users assigned to a role with the 'Export' permission may export a matrix, that may or may not have been created by this user, including the structure, guidance and forms included with the matrix.

As you can see, the permissions granted to the role are not explicitly clear from the permission name. Depending upon the use cases you are trying to support, there are a couple of different approaches we can take with the permissions.

Use Case #1: Site A has one or more Coordinator(s) who should only have permission to edit, delete, publish and export his/her own matrix/wizard OR Site C has a Coordinator and an Assistant and the Coordinator can edit, delete, publish and export everything, but the Assistant can only edit, delete, publish and export his/her own matrix/wizard.

Permissions Solution #1: In this instance, we should keep the permissions separate, but we should revise the permissions to ensure they are as explicit as possible, just as Resources has done. In this instance, the permissions for the Matrices tool would consist of the following: create, revise.any, revise.own, delete.any, delete.own, publish.any, publish.own, export.any and export.own.

Use Case #2: Site B has one or more Coordinator(s) who should have permission to create, edit, delete, publish and export any matrix in the site.

Permissions Solution #2: Combine the Create, Edit, Delete, Publish, and Export permissions into one Manage Matrices permission.

I propose that we go with Solution #1 to allow for the greatest flexibility down the road. Are there any concerns with this approach?

Comments

  • I think making the permissions explicit is a good idea... (Sean Keesler)
  • I think expanding the permissions will best support everyone's differing use cases. I'd like to tack on one more request to this work – what do you think about merging the matrix and wizard permissions? While traipsing through the code on other issues, I keep running across bugs where a user needed osp.matrix.X permission when working in wizards – so they've already been functionally merged to some degree (albeit in a undesirable, hidden implementation). (Beth Kirschner)

Action: see SAK-13719

Evaluate/View Permissions (Beth Kirschner, UM)

One of the comments we've already received involves the issue of how to give evaluator users permission to view any matrix cell, while also giving only specific users (evaluators/reviewers) permission to evaluate and/or give feedback. This problem was noted by both LOI and IU. I've copied below Mark Breuker's comment regarding this problem:

"If an evaluator has been selected as an evaluator for cell A, can s/he then also view submissions and evaluations of cell B (for which s/he is not the specific evaluator)?

In the past this was only possible if someone was selected (either by role or user) as an evaluator in both cells. For this reason we abandoned selecting specific users as evaluators per cell. Instead we selected the role Evaluator. We instructed our evaluators to only evaluate their "own" cells (i.e. cells for which they received an evaluation invitation per e-mail).

Consider the following use case:

1. Evaluator Beth has been assigned to cell A as the (only) evaluator.
2. Evaluator Lynn has been assigned to cell B as the (only) evaluator.
3. When evaluating cell B, Lynn wants to review the evaluation in cell A, created by Beth.

Two solutions were discussed at today's call (following up on a similar discussion 2 weeks ago):

1. Create new osp.matrix.view.any and osp.wizard.view.any permissions, initially granted to all users with evaluate permission. This would give evaluators the option of viewing matrix cells (or wizard pages) for which they have read-only permission (they cannot evaluate). View permission would need to be further defined – currently evaluator users can view a cell, but not the content within it.

2. Extend the current definition of the evaluate permission, such that those with evaluate permission can view a student's matrix cell, but only those specifically selected as an evaluator can update (i.e. create an evaluation).

Comments

  • We are actually running into a situation right now where evaluators want their work to be held private between themselves and the student (in Off Univ Development; opposite of DH where they don't care who sees what); which makes me lean towards the more complicated, but more long-term flexibility of option 1. (Tiffany)

Action: see SAK-13719

Singularity of Feedback (beth.kirschner/um)

Faculty/Peer-advisors have no limit on the number of feedback forms that can be provided for any particular cell or artifact. This can make data mining difficult when unique data is required (e.g. rating data). Additionally, there may be no desire for general feedback, only feedback attached to an artifact.

  1. Options must be presented on the Manage Cell screen within the Matrix configuration to: (1) allow unrestricted feedback, (2) allow only one feedback form per submitted artifact, (3) disallow general feedback
  2. These options must be respected in the Cell Detail screen to conditionally show or hide the "Add Feedback" link per item

Questions:

  • JIRA ticket or New Feature Template?
  • Should the option to even present the option be enabled/disabled in sakai.properties?
  • Matrix-wide option of per-cell option?

Action: see SAK-13406

Ability to Supply Default Text in a Form (erica.ackerman UM)

It is very useful to be able to specify the default text that will appear in the editing area of the FCKEditor. Currently, there is no simple method for doing this. For example, you cannot simply include the text in the form's XSD. The method we are using now at Michigan is to create a custom renderer (named formCreate-wysiwig.xsl) for the form. This custom renderer has an if statement saying that if the field is empty, the default text should be used. The default text is supplied by placing it in the text area that the FCKEditor replaces at runtime. This is not a scalable solution, since it requires an xsl developer just to enter the text. Two solutions have been suggested.

  • First, the text could be specified in the XSD at the time the form is created.
  • Second, there could be a mechanism for creating a prototype version of a form. In this scenario, the site owner would be able to go to a matrix cell, add a copy of the form, enter any desired default text, and then save the form as a prototype. Users who add the form would then start out with a copy of the prototype. This solution has the advantage that the same form can be used in various cells without having to modify the XSD for each cell. At Michigan, for example, we use one of two forms for all cells where web pages are being created. Having to modify the XSDs would be problematic.

Action: New Feature Template (tbd)

Side-By-Side View to Provide the User with Context for an Item

Given that ePortfolios are intended to allow reflection on previously created work, it would be very useful to provide users with a side-by-side view showing the original artifact next to a reflection or evaluation form. For example, if a user has filled out a form about an experiment and then later needs to reflect on it, the system might display both the reflection form and the content of the original form in scrollable iframes next to each other. Such an arrangement would also be helpful for evaluators.

It is not currently possible to do this because, when a form is rendered, the system (metaobj) does not have enough metadata about the parent matrix cell to know what other forms might be related to the form being rendered. For example, when the user is in the matrix and clicks on a form, the only information about the matrix that gets passed to the form is the name of the cell. Ideally, the ID of the cell and the IDs of all other forms associated with the cell would be passed as well. One suggestion is to put a wrapper around metaobj that would maintain information about context. This change alone should be enough to allow a side-by-side view of content entered into forms.

Action: see SAK-12101

Allow In-Line Viewing of Uploaded Files

There has long been a desire to display uploaded files (e.g., Word docs, PPT, attached images) in the user's browser, but an appropriate technology has not been available. It is worth investigating whether this has changed with the new availability of background processing agents that convert documents to Flash. The starting place to look into this would probably be the Macromedia Central and Flex products. A whitepaper on the use of these products can be found here: http://www.adobe.com/devnet/flex/articles/desktop_apps/flex_central_desktopapps.pdf.

As a related note, if the only solution to this problem is a proprietary piece of software, would it be useful to consider a Sakai plug-in that would allow institutions with the wherewithal to take advantage of this option?

Action: See SAK-12102

Existing JIRA issues

  1. WYSIWYG Editor Issues
    Action: see SAK-10399

Wizard Enhancements

Although release 2.5 includes several major improvements for the OSP Wizards tool, wizards have not yet reached functional parity with Matrices.  As a result, many community members are choosing to use Matrices as a workflow framework, when conceptually wizards are much better suited to this type of task as well as many others.  The enhancements below, most of which are fairly minor, are suggested with the goal of moving wizards closer to functional parity with Matrices.

  1. Add support for deep linking to a specific wizard - currently it is possible to copy the URL for a specific matrix to the clipboard (by right-clicking on the title in the Manage Matrices screen) and expose the matrix in another site via the Web Content tool.  This feature has proven extremely useful for making a single programmatic matrix available to students any course and/or project site.  Adding the equivalent capability to Wizards would significantly increase the utility of that tool. 
    Action: Needs a Feature Request spec
  2. Add color coding to status column - As of release 2.5, the main page of a user's wizard includes a status column that indicates the status of each page using text labels.  While the text labels represent a huge improvement over previous versions, color coding the labels in a manner similar to the color coding of matrix cells would make to possible for the student, instructor, and/or evaluator to process the status information much more quickly and easily.  See Wizard Status and Workflow Progression Mockups for some preliminary ideas..
    Action: see SAK-13144
  3. Add support for workflow progression - Currently, there are two types of wizard, a hierarchical wizard and a sequential wizard.  The hierarchical wizard is completely lacking in workflow support and the sequential wizard offers only one workflow option--start at the beginning and work forward in a linear progression.  The sequential wizard is also extremely awkward to use (is anyone really using it???)  Once enhancement 2 above (color coding) is implemented, it should be possible to add workflow progression similar to that found in Matrices.  Options might include:
    • All pages begin as open and follow the "pending-->completed" behavior.
    • The page at the top begins as ready; pages underneath begin as locked. Page underneath opens when page on top is submitted.
    • The page at the top of each category begins as ready; in the same category begin as locked. Pages underneath opens when page on top is submitted.
    • Determined by instructor.  Pages begin as configured and are opened on demand.
      Action: Needs a Requirements Proposal writeup
  4. Add/move page or category after publishing -   With release 2.4, it became possible to add or move a column or a row in a matrix after publishing.  Providing similar functionality in the wizard would better support the evolving needs of users.
    Action: see SAK-13145
  5. Delete category and/or page -  similar to the delete row/column option in Matrices, this feature would allow a page or category to be deleted, provided no data has been published to the wizard.
    Action: see SAK-13145
  6. Aggregated Wizards - enable an aggregated view of the Wizards tool in My Workspace.
    Action: Existing JIRA Issue SAK-10136
  7.  UMich 2.5 Enhancements to Matrices (which could also be applied to Wizards)
  8. Improve wizard performance - For some reason, open the Wizards tool and navigating among wizards and wizard pages takes much longer than the equivalent actions in Matrices.  Reducing the page write/refresh times would greatly improve usability.
    Action: Write up specific performance issues in JIRA and/or confluence
  9. Submit entire wizard - Currently, clicking Submit on the main page of a hierarchical wizard or Submit Entire Wizard within a sequential wizard does not actually submit the other pages of the wizard.  This item proposes changing the button on the main page of a hierarchical wizard to "Submit entire wizard".  Clicking this button (or the equivalent function in a sequential wizard) would submit all heretofore unsubmitted pages with evaluation forms and lock all pages without evaluation forms.
    • If the main page includes an evaluation form, the main page and all pending subpages containing evaluation forms appear in the Evaluations tool.
    • If the main page does not include an evaluation form, all pending subpages containing evaluation forms appear in the Evaluations tool.
    • When the evaluator completes an evaluation form on the main page, s/he is give the option to:
      • Set main page and all subpages to Complete
      • Set the main page to Complete and leave subpages unchanged so they may be evaluated individually
        Action: Needs a Feature Request spec
  10. Integrate Matrices and Wizards into a single tool called "Guided Portfolios" - this or something similar has been on the books for a long time.  Aside from helping users recognize that matrices and wizards are just two different ways of arranging portfolio activities within a visual framework, perhaps it would help ensure that future enhancements are applied to all guided portfolio types rather than the matrix only.
    Action: Needs a Feature Request spec
  11. Add custom form as an option on main page of wizard -  At IUPUI, we have some portoflio projects that would benefit from the presence of an optional form on the main page of a hierarchical wizard.  As an example, we would like to implement a wizard that allows students to give informed consent required by our institutional research board.  We tried implementing within the existing functionality of the matrix and wizard and the process required so many clicks that we have resorted to a paper form.
    Action: see SAK-13146

Fix "Back Button" problem

Action: see SAK-7880 (3.17.08)

Allow saving, editing and removing of evaluations in progress

Currently if an evaluator creates an evaluation for a matrix cell there's no way of editing or removing the form once the evaluator clicks on the submit button. The only option the evaluator has is to select the workflow option that keeps the cell in pending status and then create another evaluation. It would be nice if an evaluator could create a form, save his work in progress, continue the next day and be able to remove any previous forms he created. The student should only see the evaluation after the cell has been approved or rejected.

Action: see http://bugs.sakaiproject.org/jira/browse/SAK-13091 (3.17.08)

Ability to Add Multiple Rows and Columns When Creating a Matrix

Creating a complex matrix would be much less painful if there were a single page that allowed you to specify the names and labels of several columns at one time. Same with rows. (Perhaps similar to 2.5.x's Resources > Upload Files > Add Another file?)

Action: thumbs up and needs to be written up in JIRA (3.17.08)