fix: Update permissions for course team tab in Instructor Dashboard

[brianjbuck-wgu]

Description

Restricts the Instructor Dashboard Course Team tab and its associated API endpoints to only the Admin (instructor
role) and Discussion Admin (staff + forum Administrator role). Previously, the tab was visible to all staff-level users and the endpoints only allowed the instructor role, blocking Discussion Admins.

Supporting information

Closes #38439

Testing Instructions

1. Log in as a user with the Staff role on a course.

2. Navigate to the Instructor Dashboard via /api/instructor/v2/courses/{course_id}.

3. Verify the course_team tab is not present in the tabs.

4. Attempt to access /api/instructor/v2/courses/{course_id}/team should return 403.

5. Log in as a user with the Admin (instructor) role.

6. Verify the course_team tab is present in the tabs.

7. Verify /api/instructor/v2/courses/{course_id}/team returns 200.

8. Log in as a user with Staff + Discussion Admin (forum Administrator) roles.

9. Verify the course_team tab is present in the tabs.

10. Verify /api/instructor/v2/courses/{course_id}/team returns 200.

11. Verify POST (grant/revoke) and DELETE operations on the team endpoints also return 200.

12. Log in as a non-staff user who only has the forum Administrator role.

13. Verify the course team endpoints return 403.

Other information

No database migrations required.

[openedx-webhooks]

Thanks for the pull request, @brianjbuck-wgu!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[Copilot]

Pull request overview

Updates Instructor Dashboard “Course Team” visibility and backend access control to align course team management with intended roles.

Changes:

• Restricts the course_team tab to users with instructor access or discussion “Administrator” role.
• Switches course team API endpoints to a new CourseTeamPermission.
• Adds/updates tests to validate tab visibility and endpoint access for forum admins vs plain staff.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
lms/djangoapps/instructor/views/serializers_v2.py	Gates course_team tab behind instructor or forum_admin access.
lms/djangoapps/instructor/views/api_v2.py	Applies CourseTeamPermission to course team endpoints.
lms/djangoapps/instructor/tests/test_api_v2.py	Updates tab expectations; adds coverage for forum admin tab visibility and endpoint access.
lms/djangoapps/instructor/permissions.py	Introduces CourseTeamPermission to allow instructor or forum Administrator role access.

Comments suppressed due to low confidence (1)

lms/djangoapps/instructor/tests/test_api_v2.py:3510

• These new tests cover a staff user who is also a discussion "Administrator". Given CourseTeamPermission currently keys only off has_forum_access(), it would be valuable to add a test for a non-staff user with the forum Administrator role (UserFactory + role assignment) to ensure the intended security boundary is enforced (either 200 if truly intended, or 403 if staff should be required).

class CourseTeamEndpointForumAdminAccessTest(SharedModuleStoreTestCase):
    """
    Tests that Discussion Admin (forum Administrator role) can access
    course team endpoints, not just the instructor role.

    See: https://github.com/openedx/openedx-platform/issues/38439
    """

    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        cls.course = CourseFactory.create(
            org='edX',
            number='ForumAccess',
            run='2024',
            display_name='Forum Admin Access Test Course',
        )
        cls.course_key = cls.course.id

    def setUp(self):
        super().setUp()
        self.client = APIClient()

        # Discussion Admin: staff + forum Administrator role
        self.forum_admin = StaffFactory.create(course_key=self.course_key)
        seed_permissions_roles(self.course_key)
        admin_role = Role.objects.get(course_id=self.course_key, name='Administrator')
        admin_role.users.add(self.forum_admin)

        # Plain staff user (no forum admin, no instructor) — should be denied
        self.staff_user = StaffFactory.create(course_key=self.course_key)

    def test_forum_admin_can_list_team_roles(self):
        """Discussion Admin should be able to GET /team/roles."""
        url = reverse('instructor_api_v2:course_team_roles', kwargs={'course_id': str(self.course_key)})
        self.client.force_authenticate(user=self.forum_admin)
        response = self.client.get(url)
        assert response.status_code == status.HTTP_200_OK

    def test_forum_admin_can_list_team_members(self):
        """Discussion Admin should be able to GET /team."""
        url = reverse('instructor_api_v2:course_team', kwargs={'course_id': str(self.course_key)})
        self.client.force_authenticate(user=self.forum_admin)
        response = self.client.get(url)
        assert response.status_code == status.HTTP_200_OK

    def test_forum_admin_can_grant_role(self):
        """Discussion Admin should be able to POST /team to grant a role."""
        url = reverse('instructor_api_v2:course_team', kwargs={'course_id': str(self.course_key)})
        target = UserFactory.create()
        self.client.force_authenticate(user=self.forum_admin)
        response = self.client.post(url, {
            'identifiers': [target.username],
            'role': 'staff',
            'action': 'allow',
        }, format='json')
        assert response.status_code == status.HTTP_200_OK

    def test_forum_admin_can_revoke_role(self):
        """Discussion Admin should be able to DELETE /team/{username}."""
        target = StaffFactory.create(course_key=self.course_key)
        url = reverse(
            'instructor_api_v2:course_team_member',
            kwargs={'course_id': str(self.course_key), 'email_or_username': target.username},
        )
        self.client.force_authenticate(user=self.forum_admin)
        response = self.client.delete(url, {'roles': ['staff']}, format='json')
        assert response.status_code == status.HTTP_200_OK

    def test_plain_staff_cannot_access_team_endpoints(self):
        """Staff without instructor or forum admin role should get 403."""
        url = reverse('instructor_api_v2:course_team', kwargs={'course_id': str(self.course_key)})
        self.client.force_authenticate(user=self.staff_user)
        response = self.client.get(url)
        assert response.status_code == status.HTTP_403_FORBIDDEN

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dwong2708]

LGTM, thanks for the effort!

[wgu-taylor-payne]

CourseTeamPermission allows Discussion Admins (staff + forum Administrator) to access all course team endpoints, including POST /team which can grant any role in VALID_TEAM_ROLES. Since that set includes instructor, a Discussion Admin can grant themselves — or anyone — the instructor role, escalating their own privileges.

The existing ForumAdminRequiresInstructorAccess class already handles this pattern for forum roles: when the target role is FORUM_ROLE_ADMINISTRATOR, only instructors are allowed to proceed. The same guard is needed here for the instructor course role, on both the grant (POST) and revoke (DELETE) paths.

A minimal fix in CourseTeamView.post, after the serializer validation:

rolename = serializer.validated_data['role']
action = serializer.validated_data['action']

if rolename == 'instructor' and not has_access(request.user, 'instructor', course):
    return Response(
        {'error': _('Managing the instructor role requires instructor access.')},
        status=status.HTTP_403_FORBIDDEN,
    )

And the same pattern in CourseTeamMemberView.delete — if 'instructor' in roles, the requesting user should have instructor access.

Review assisted by Kiro

[brianjbuck-wgu]

CourseTeamPermission allows Discussion Admins (staff + forum Administrator) to access all course team endpoints, including POST /team which can grant any role in VALID_TEAM_ROLES. Since that set includes instructor, a Discussion Admin can grant themselves — or anyone — the instructor role, escalating their own privileges.

The existing ForumAdminRequiresInstructorAccess class already handles this pattern for forum roles: when the target role is FORUM_ROLE_ADMINISTRATOR, only instructors are allowed to proceed. The same guard is needed here for the instructor course role, on both the grant (POST) and revoke (DELETE) paths.

A minimal fix in CourseTeamView.post, after the serializer validation:

rolename = serializer.validated_data['role']
action = serializer.validated_data['action']

if rolename == 'instructor' and not has_access(request.user, 'instructor', course):
    return Response(
        {'error': _('Managing the instructor role requires instructor access.')},
        status=status.HTTP_403_FORBIDDEN,
    )

And the same pattern in CourseTeamMemberView.delete — if 'instructor' in roles, the requesting user should have instructor access.

Review assisted by Kiro

@wgu-taylor-payne, Good catch! PR Updated!

[wgu-taylor-payne]

Looks good, thanks!