Support for Legacy Functionalities

As the unified user grouping model is introduced, it is essential to ensure continued support for key platform features that currently rely on legacy grouping mechanisms such as Cohorts, Teams, and Enrollment Tracks. These features include content gating, divided discussion forums, and customized ORA assignments.

To preserve platform functionality and maintain backward compatibility, this section outlines how these existing capabilities can be adapted to work with the new user grouping system. The goal is to ensure a smooth transition without disrupting the learner or instructor experience while gradually replacing legacy dependencies under the hood.

Content Gating

Currently, content access control is available for Cohorts, Enrollment Tracks, and Teams. Similar to how dynamic partitions are generated for Enrollment Tracks and Teams, the following should be done:

• Create a partition for User Grouping (UserGroupingPartition), which will generate a group for each user group created.

• When course content is loaded in the LMS, the UserPartitionTransformer collects the blocks the user can access. In that process, the registered Course Outline Processors are called. Among them, there will be the UserGroupingOutlineProcessor, which filters the blocks the user is allowed to access.

Divided Discussion Forum

Currently, the discussion division only works with Cohorts. This division is enabled from:
Studio > Content > Pages & Resources > Discussion > Settings > Divide discussions by Cohorts.

Group-based filtering of discussions is handled in the forum app. The CommentThread model stores all discussion posts and includes a group_id field. Depending on the user making the request, only posts from the group the user belongs to and posts without a group_id (i.e., visible to all) are returned.

To adapt this functionality, the following should be done:

• Modify the logic to obtain multiple group_id (User Groups) for the user. Currently, with Cohorts, the user belongs to only one group, and that single group_id is used for filtering. With user groups, it should allow N groups.

• Modify the group_id field to accept multiple IDs, in case a post needs to be visible to several user groups. This would also apply to post replies and comments on replies.

Custom ORA Assignments

Currently, a feature in ORA assignments allows restricting participation to students who belong to a specific Team Set. This is configured within the ORA settings in Studio. Specifically, there are two fields:

• teams_enabled: indicates whether the team restriction is active.

• selected_teamset_id: indicates the ID of the Team Set.

Here is some documentation on the functionality:

• https://docs.openedx.org/en/open-release-sumac.master/educators/how-tos/course_development/exercise_tools/CreateORAAssignment.html#team-open-response-assessments

• https://docs.openedx.org/en/open-release-sumac.master/educators/how-tos/course_development/exercise_tools/CreateORAAssignment.html#team-vs-individual-ora

To adapt this feature, the following should be done:

• Modify the teams_enabled field to support the new user groups (user_groups_enabled).

• Modify the selected_teamset_id field to match the new user group configuration (selected_user_group_id).

• Update all related logic that checks if a user belongs to a TeamSet, so that it instead verifies whether the user belongs to the configured user group in the ORA assignment.

• Update all logic that lists available TeamSets in the course within the ORA configuration, so that it instead lists all user groups.