fix(courseware): restore anonymous video viewing on public courses

[kingoftech-v01]

Description

Anonymous (unauthenticated) users trying to view video blocks on public courses receive a 500 or 404 error depending on the code path. The Learning MFE's sidebar navigation call fails with TypeError: Cannot cast AnonymousUser to int, and render_xblock returns 404 for blocks with inherited future start dates.

User impact (Learner / Visitor): Anonymous users can once again browse and view video blocks on public courses that have the unenrolled-access waffle enabled.

Root Cause

Three distinct defects combined to break this feature:

Bug 1 — lms/djangoapps/course_home_api/outline/views.py:608-625
CourseNavigationBlocksView.completions_dict queries BlockCompletion.objects.filter(user=self.request.user, ...) with no anonymous guard. For AnonymousUser, Django's FK coercion to user_id=None raises TypeError: Cannot cast AnonymousUser to int. Introduced in commit 30836729b7c (PR #34457 "Implement Sidebar Navigation [FC-0056]"). The sibling code at line 354 already had if not request.user.is_anonymous guards — the new view simply missed the pattern.

Bug 2 — lms/djangoapps/courseware/access.py:377-383 (_has_access_course.can_load)
check_course_open_for_learner() returns StartDateError for anonymous users on public courses with a future start date. render_xblock catches CourseAccessRedirect and converts to Http404. The public-visibility feature was threaded through check_enrollment and check_authentication in access_utils.py but the course-level can_load path in access.py was never updated to bypass check_course_open_for_learner for public courses.

Bug 3 — lms/djangoapps/courseware/access.py:597-629 (_has_access_to_block.can_load)
Same gap at the block level: check_start_date(user, ...) is called with no public-course bypass. Blocks with inherited future start dates return StartDateError → get_block_for_descriptor returns None → Http404.

Fix

Three surgical edits in two files. All gating reuses the existing check_public_access() from access_utils.py so the contract COURSE_ENABLE_UNENROLLED_ACCESS_FLAG + COURSE_VISIBILITY_PUBLIC continues to govern who sees what.

lms/djangoapps/course_home_api/outline/views.py — completions_dict short-circuits to {} for anonymous users. Anonymous users have nothing to mark complete anyway, and mark_complete_recursive already handles missing completions gracefully.

lms/djangoapps/courseware/access.py — add check_public_access and COURSE_VISIBILITY_PUBLIC imports, then:

1. In _has_access_course.can_load, add an early-return granting access when user.is_anonymous and check_public_access(courselike, [COURSE_VISIBILITY_PUBLIC]).
2. In _has_access_to_block.can_load, mirror the bypass at the block level — look up CourseOverview from the provided course_key and apply the same check. Group access is still honored (checked above), so cohort/partition gating continues to apply.

Authenticated users, masquerading staff, and non-public courses are unaffected. The bypass only fires when user.is_anonymous is True AND the course is public AND the waffle is enabled.

Supporting Information

• Issue: Anonymous video viewing is broken #38019
• Closed attempt: PR Fix: Video public view for anonymous users on public courses #38015 (self-closed, explicitly marked "vibe coding using Cursor... created for the testing purpose")
• Bug 1 introduced: commit 30836729b7c (PR feat: [FC-0056] Implement Sidebar Navigation #34457 "Implement Sidebar Navigation [FC-0056]")
• Bugs 2 & 3: pre-existing gaps in public-course coverage that surfaced when the Learning MFE started calling render_xblock for anonymous users

Testing Instructions

1. Enable course_experience.course_enable_unenrolled_access waffle flag.
2. Create a public course (course_visibility='public') with a future start date and a video block.
3. As an anonymous (logged-out) user, navigate to the course outline and click the video.
4. Before the fix: 500 error on the sidebar API or 404 on the video block.
5. After the fix: the video loads and plays.
6. Verify authenticated unenrolled users still work.
7. Verify non-public courses still block anonymous access.
8. Verify a public course with course_enable_unenrolled_access disabled still blocks anonymous access.

Four new tests in lms/djangoapps/courseware/tests/test_access.py::AccessTestCase:

• test_unit_anonymous_can_load_public_course_with_future_start
• test_unit_anonymous_denied_when_unenrolled_access_flag_off
• test_integration_anonymous_can_load_block_on_public_course
• test_bug_38019_regression_anonymous_still_denied_on_non_public_future

Deadline

None

Other Information

• No database migrations
• No new dependencies
• No deprecations
• The WebpackBundleLookupError mentioned in PR Fix: Video public view for anonymous users on public courses #38015 (xmodule/video_block/video_block.py::public_view) is a separate webpack-build concern — out of scope here, to be filed separately. The access-chain fix in this PR is a strict prerequisite to reaching that code path.
• completions_dict result is still cached per-request via @cached_property.
• CourseOverview.get_from_id is already memoized at the request layer, so the new block-level lookup adds negligible cost.

Closes #38019

[openedx-webhooks]

Thanks for the pull request, @kingoftech-v01!

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

🔘 Submit a signed contributor agreement (CLA)

⚠️ We ask all contributors to the Open edX project to submit a signed contributor agreement or indicate their institutional affiliation.
Please see the CONTRIBUTING file for more information.

If you've signed an agreement in the past, you may need to re-sign.
See The New Home of the Open edX Codebase for details.

Once you've signed the CLA, please allow 1 business day for it to be processed.
After this time, you can re-run the CLA check by adding a comment below that you have signed it.
If the CLA check continues to fail, you can tag the @openedx/cla-problems team in a comment for further assistance.

🔘 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.