• If the ReverificationBlock is part of a content experiment, its grandparent will not be a Subsection, so it will control access to its siblings within the experiment, but not any surrounding content.  This is arguably a reasonable way to handle this case.

• If two or more ReverificationBlocks are children of the same Vertical or grandchildren of the same Subsection, then users in a verified track will not be able to see either block (or any of the content).  Intuitively, reverification checkpoint #1 prevents access to checkpoint #2, and vice-versa.  While potentially confusing, there is at least an easy way for course authors to fix the issue: delete all but one of the ReverificationBlocks in a particular subsection.

Partition Scheme

The LMS supports pluggable partition schemes.  We will define a new partition scheme that places users into one of the three groups as follows:

def get_group_for_user(cls, course_key, user, user_partition):
    checkpoint = user_partition.parameters[“location”]

	if (
        not _is_enrolled_in_verified_mode(user, course_key) or
        _was_denied_at_any_checkpoint(user, course_key)
    ):
		return NON_VERIFIED_GROUP
    elif (
         _has_skipped_any_checkpoint(user, course_key) or
         _has_completed_checkpoint(user, course_key, checkpoint) or
         _has_preview_permission(user, course_key)
    ):
      	return VERIFIED_ALLOW_GROUP
    else:
	    return VERIFIED_DENY_GROUP

Preview

Course staff need to be able to preview exam content that is gated by an in-course reverification.  Our existing access control logic will automatically grant global and course staff access to the ICRV XBlock and exam content regardless of the user's group.  In other words, we get the desired behavior for course staff with no additional development effort.

Messaging for Blocked Content

Currently, when a user is denied access to courseware content, the content is completely hidden from the user.  One potential enhancement would be for the access checks to provide additional messaging in certain cases to explain to users why they were blocked from accessing content.  This proposal does not address messaging for blocked content, except to note that it is compatible with this approach.

There is currently no way to display a “disabled” version of blocked content (for example, displaying the content as “grayed out” with functionality disabled).  It is unclear how we could support this functionality without significant changes to the LMS.

Performance

Access Checks

The main performance risk with this approach is that the user partition scheme will be called whenever a user tries to load a courseware component.  Unlike with cohorts or content experiments, a user’s group can change as the user’s verification and enrollment states change.  For this reason, we need a slightly more sophisticated cache invalidation strategy.

We propose caching the following information:

Course Publish

The proposed approach requires querying and modifying course content on publish.  To avoid a potential race condition, this operation will be performed synchronously on publish.  Publishing in Studio happens frequently, so these modulestore operations need to be efficient.  We can optimize by retrieving all in-course reverification blocks, then following “parent” and “children” links to find the blocks we need to update.

We will need to test the performance of this operation on a course with many components.  If the operation is slow enough that it negatively impacts the course authoring experience, we have the option of making the update asynchronously.  This introduces at least two potential race conditions:

• Students can access gated content after it is published but before the asynchronous task updates it.

• Multiple worker processes attempt to update a course at the same time, overwriting changes from other processes.

Addressing these issues would likely require introducing a locking mechanism to coordinate task execution among workers, which would involve additional design, development, and testing.

Alternative Approaches

Parent “Exam” Block 

One alternative we considered was to introduce a new navigational XBlock for representing exam content.  Assessment content would be added as children of the parent exam block.  The exam block could then query the user’s permission to access exam content through an XBlock service and dynamically show or hide its children.

Although we believe that this approach is technically feasible, we feel that there is value in using a more constrained API for access control.  To determine the structure of a course with XBlocks that have dynamic children, the XBlocks must be instantiated.  This makes it difficult to represent and reason about the course structure.  It also prevents future optimizations such as caching the course structure for users in a particular group.

Milestones

Another alternative we considered was to use the Milestones microservice.  This service is currently used to implement entrance exams (prevent access to a course until the user passes an exam) and pre-requisite courses (prevent access to a course until the user completes a prerequisite course).

Milestones provide an intuitive model for binary states: for example, a user has either completed a prerequisite exam or the user hasn’t.  However, verification states are not binary -- this is why we introduced three partition groups when modeling the problem as user partitions.  It may be possible to model these states using multiple milestones, but this introduces significant complexity.

In addition, milestones require that we keep the user’s acquired milestones in sync with the user’s verification and enrollment states.  This could introduce errors that are difficult to prevent, diagnose, and fix.  In contrast, user partition schemes dynamically calculate the user’s group based on the user’s verification and enrollment state, so no synchronization is necessary.

Linearized Navigation

We considered performing a depth-first search of the course structure and saving the traversal order to a database table.  We could then add access checks of the form: “restrict access to every component after location X”.

We ultimately rejected this approach after reviewing the courseware navigation API proposed by the mobile team.  Enforcing a linear order on courseware content would make it difficult to support different navigation strategies, especially for adaptive learning.