Section Awareness API Requirements

Owned by Former user (Deleted)
Last updated: Jul 28, 2005Version comment
3 min read

Section Awareness API Requirements

Based on our walkthroughs, the initial set of API requirements are fairly simple and generic. I'll use the word "sections", but we could call these things "user groups" as far as section-aware applications other than Section Management are concerned.

The following procedural service names are meant to give an abstract idea of what's required. Optimized queries (e.g., "findGroupsMembersPagedBySortName", "getUnassignedMembers") are TBD. Also, as object-oriented programmers, I imagine we'll likely prefer calls like "section.getName()" to calls like "service.getSectionName(sectionId)".

Related services (getting a context ID to start from, getting the currently logged-in user's personId, getting a person's name, and so forth) aren't mentioned here.

There are three roles that we're interested in for 2.1: "instructor" (equivalent to "administrator"), "student", and "teaching assistant". Students and teaching assistants have permissions scoped by section membership; instructors are assumed to have instructor access to all sections. A more flexible approach, supporting fine-grained permissions scoped by section membership, is not a requirement for Sakai 2.1 although it is likely to be required in the future.

Site context methods

  • getSections(contextId)
  • getSectionCategories(contextId)
  • getMembers(contextId)
  • getMembersInRoles(contextId, ROLE) - "ROLE" is one of "instructor", "student", or "teaching assistant".
  • isMemberInRole(contextId, personId, ROLE)

Section methods

  • getSectionMembers(sectionId)
  • getSectionMembersInRole(sectionId, ROLE)
  • isSectionMemberInRole(sectionId, personId, ROLE)
  • getSectionName(sectionId)
  • getSectionCategory(sectionId)

Section category methods

  • getSectionsInCategory(categoryId)
  • getCategoryName(categoryId).

If we support course-wide teaching assistants, there are a couple of different ways to deal with them in this mock API. Pick one of the following options:

  • Add "isMemberSectionScoped(contextId, personId)" - The assumption here is that "teaching assistant" permissions may be site-wide or section-scoped.
  • Add two new roles instead of one: "head TA" and "section leader".
  • Accept an ID for the entire course as a legitimate "sectionId" argument.

The UI equivalents to these API options might be thought of as:

  • Include a "For entire course" checkbox in the teaching assistant role assignment.
  • When adding new members, have the user choose from the role list "Instructor", "Head TA", "Section Leader", and "Student".
  • Add "ALL" to the top of the list of sections available when assigning a teaching assistant.

(NOTE: The current Course Management API doesn't distinguish between instructors and TAs, which means that figuring out an easy model for course-wide TAs requires more than what's on the surface. If we store and retrieve our data strictly through Course Management as currently specified, we'll have to rely on those dreaded out-of-band agreements. Alternatively, we could use Sakai course-scoped roles to distinguish the two cases and use Course Management just to handle membership. For whatever the information's worth, the "IMS Enterprise Best Practice and Implementation Guide" includes the course-or-section membership role types "Learner", "Instructor", "Content Developer", "Manager", and "Teaching Assistant", all of which map pretty well to LMS application permissions we're interested in.)

POST 2.1 - Section-scoped application permissions

Once section-scoped query-friendly permissions are supported, individual applications may want to use that more generic and flexible approach. To make application use of the above methods clearer, I'll list our current understanding of those permissions below. But we've agreed that in Sakai 2.1 queries on such section-scoped permissions would be equivalent to the role-based queries documented above.

  • assessments.score
  • assessments.author
  • assessments.access
  • announcements.maintain
  • announcements.access
  • email.access

Section Management requirements

These will have to be filled in by Josh. But as a start, we know that the Sections Tool will also need support for:

  • Modifying section membership
  • POSSIBLY modifying site membership and roles (depending on how the conflicts between Course Management and the legacy "Site Info" tools get resolved)
  • Accessing a wider range of section and category metadata