Note that this is a preliminary account of work done on an Assignments ("one"/ "legacy") data feed. This work was done to address a very specific dashboardscenario at the University of Michigan for a portfolio need. A complete data feed has not been created, but many of the fundamental issues have been encountered. The feed represents one type of query - that of an "assignment" as how a student conceives of it (technically, a marriage between the assignment and submission entities).

The problem being solved

Mapping assignments and other types of activities/references into a cohesive dashboard. The view is per-student whether the viewer is a student or mentor. Here is a simple mock-up illustrating the overall concept:
 

Things needed to get there

• A consistent set of status indicators to apply to each activity (scoped to individual participants).
  • Items that are not interactive get a static state.
  • Items that are interactive should all be mapped to the same semantics.
• A way to treat the activities generically and consistently until specifics are needed.

Each kind of item can have its own resolver and renderer (plugin model) to accommodate any number of activity types. I just need to be able to resolve each to capture the status, a "due date", a title, and a link to view the activity (again, per-participant).

The initial list of activity types needed is:

• External reference documents (not interactive)
• Sakai Assignments
• An external survey (one-off integration with a custom QuestionMark-digesting database)
• A custom, one-shot prompt-response-feedback interaction (not based on course roles, so is not in Assignments)

An initial list of statuses is:

• Not Opened – Not yet available (all item types)
• Reference – Materials available for viewing
• Open – Any activity that can be started
• In Progress – Any activity that has been started but not completed/submitted
• Submitted – Reviewable activity awaiting review
• Returned – Reviewable item that has been returned for resubmission
• Completed – Any activity that has been finished or finally reviewed
• Closed – Any activity that was not completed, but is no longer available (missed)

Note that this neglects some complexities around "late" items and resubmission drafts for now

Work done specifically with the Assignments code

• Working through the service API and implementation to understand how each entity's status is calculated.
• Going through the views and following the transitions to see what actions are available at each.
• Reimplementation all of the state determination and thinking through resolution into a stable student pserspective (even when submission is not yet possible, etc.).
• Making a data feed available to ask for the status of an assignment for a named student, which does not disclose any more than the tool

See: https://source.sakaiproject.org/contrib/reporting/extraction-umich/branches/ctools-fa08/impl/src/java/edu/umich/ctools/extraction/AssignmentInfo.java

Complaints/Critiques/Stumbling blocks

• Security for viewing/editing is all at the site level, so I had to walk through the views and come up with the disclosure rules and "true" role-based permissions against objects.
  • Much of this permission is implemented in the view layer, so it requires inference of real business rules and reimplementation outside.
• Assignment.getStatus and AssignmentSubmission.getStatus both return localized, assembled strings, so they cannot be used for any logic - reimplementation is required.
• No real notion of getting the status of an "assignment for student" - Have to re-roll all combination logic
• AssignmentService.canUpdateSubmission is misleading (pass submission reference and get assignment-scoped boolean, falling through to permission to submit any assignment - disclosure risk).
• AssignmentService.getSubmission(String, User) returns null rather than PermissionException - inconsistency in behavior between similar methods.
• The existing code uses a mix of nullness and time checks to determine state - gets complicated and possibly unstable on resubmit flow.
• Graded, returned, released, submitted are not clear - For example, if resubmitted, does the returned bit flip off? Is this an "ever returned" bit?
• Security at the API should be clear - am I working with a privileged thing that I have to wrap and check, or is it taken care of so the current user cannot do anything "illegal"?