[asadali145]

Description

Adds nine filters so a plugin can adjust how course content is presented to a learner on each request: blocks right after they are bound to the learner, the learner's transformed course block structure, and the serialized course outline, metadata, progress, dates, course home outline and navigation API responses.

Today the content filters are render-time only (VerticalBlockChildRenderStarted, RenderXBlockStarted, VerticalBlockRenderCompleted). They do not run on XBlock handler requests (problem Submit / Reset / Show Answer, ORA steps), on sequence metadata (unit titles), on course pages (custom pages, handouts, updates, about), or on the cached block structure and outline behind the course outline, navigation sidebar, breadcrumbs, dates and progress page. A change a plugin makes at render time is therefore lost as soon as the learner interacts with the block or opens the outline.

New filters:

Filter	Type	Arguments	Purpose
LearnerXBlockBound	org.openedx.learning.xblock.bound.v1	block, user, course_key	Runs every time the LMS binds a block to a learner (renders, children, handlers, sequence metadata, course pages), after the access check and before any view or handler reads the block's fields.
CourseBlocksTransformCompleted	org.openedx.learning.course_blocks.transform.completed.v1	block_structure, user, starting_block_usage_key	Runs on the learner's transformed course block structure. The structure is a per-request copy, so steps can use override_xblock_field without touching the shared block structure cache.
CourseOutlineAPIRenderStarted	org.openedx.learning.course_outline.api.render.started.v1	course_key, user, data	Serialized learning_sequences course outline (breadcrumbs, "next up"). Only serialized data is passed because the outline objects are cached.
CourseHomeMetadataAPIRenderStarted	org.openedx.learning.course_home_metadata.api.render.started.v1	course_key, user, data	Serialized course home metadata (course title, tab names).
CoursewareMetadataAPIRenderStarted	org.openedx.learning.courseware_metadata.api.render.started.v1	course_key, user, data	Serialized courseware metadata (course name).
CourseHomeProgressAPIRenderStarted	org.openedx.learning.course_home_progress.api.render.started.v1	course_key, user, data	Serialized progress tab (grading policy, grade summary, section scores). user is the learner whose progress is shown.
CourseHomeDatesAPIRenderStarted	org.openedx.learning.course_home_dates.api.render.started.v1	course_key, user, data	Serialized dates tab.
CourseHomeOutlineAPIRenderStarted	org.openedx.learning.course_home_outline.api.render.started.v1	course_key, user, data	Serialized course home outline tab (blocks, dates widget).
CourseNavigationAPIRenderStarted	org.openedx.learning.course_navigation.api.render.started.v1	course_key, user, data	Serialized courseware navigation sidebar.

For the response filters, user is the user the response is built for: the learner whose data is shown, also when staff view it or masquerade as them.

Example uses: per-learner or per-cohort content variants, accessibility adjustments to block text, or presenting alternative course content without duplicating the course.

Each filter follows the existing pattern in src/openedx_filters/learning/filters.py (standalone class, Purpose / Filter Type / Trigger docstring sections, run_pipeline with named arguments) and has a test in src/openedx_filters/learning/tests/test_filters.py.

Supporting information

• Platform PR that calls these filters: feat: call filters for learner block binds and course API responses openedx-platform#39269

Testing instructions

1. make requirements (or uv sync), then pytest src/openedx_filters/learning/tests/test_filters.py.
2. make quality (ruff, pycodestyle, pylint including the filter-docstring checks, mypy).
3. End to end: install this branch in an LMS running the platform PR above, register a pipeline step on one of the new filter types in OPEN_EDX_FILTERS_CONFIG (for example one that changes block.display_name in memory for LearnerXBlockBound), and confirm it runs when loading a unit, submitting a problem, and opening the course outline.

Deadline

None.

Other information

• No breaking changes: only new filters.
• LearnerXBlockBound runs for every block bind. With no pipeline configured, run_pipeline returns immediately; steps should return early when they have nothing to do.
• Open to renaming the filters or splitting LearnerXBlockBound into narrower per-view filters if reviewers prefer.

Checklists

Merge Checklist:

• All reviewers approved
• Reviewer tested the code following the testing instructions
• CI build is green
• Documentation updated (not only docstrings)
• Code dependencies reviewed
• Fixup commits are squashed away
• Unit tests added/updated
• Noted any: Concerns, dependencies, migration issues, deadlines, tickets

Post Merge:

• Delete working branch (if not needed anymore)
• Upgrade the package in the Open edX platform requirements (if applicable)

[openedx-webhooks]

Thanks for the pull request, @asadali145!

This repository is currently maintained by @openedx/committers-openedx-filters.

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]

🟢 Approval recommended

The additive filters follow existing pipeline contracts, with no identified blocking issues.

No open issues 🎉

What changed in this PR

Adds five public filters so plugins can customize learner-specific content beyond render-time hooks.

Changes:

• Adds filters for bound XBlocks and transformed course block structures.
• Adds filters for serialized course outline, course home metadata, and courseware metadata responses.
• Documents filter contracts and adds pass-through tests.

File	Description
src/​openedx_filters/​learning/​tests/​test_filters.py	Tests return values for all five new filters.
src/​openedx_filters/​learning/​filters.py	Defines the filters, pipeline arguments, and trigger documentation.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The additions follow existing pipeline contracts, match the companion platform callers, and have no identified blocking issues.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The additive filters follow existing pipeline contracts, with no blocking issues identified.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The documented pipeline-step return value would cause plugin implementations following it to skip subsequent steps.

1 open issue

• Require pipeline steps to return a block-wrapping dictionary · New

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The additions follow existing pipeline conventions, with no unresolved blocking issues identified.

No open issues 🎉

1 resolved since last review

• Require pipeline steps to return a block-wrapping dictionary

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The additive wrappers follow existing pipeline patterns, and no unresolved blocking issues were identified.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

There are no active review issues for the new block and course API response filters.

No open issues 🎉

_{Review effort: Balanced}