feat: add subscriber platform plugin POC with learner dashboard course categorization API.

[pavanhalesh]

Overview

This PR introduces a platform plugin that exposes a new LMS API endpoint to retrieve and categorize a learner’s enrolled courses into:

• subscription_courses
• upgradeable_courses
• non_upgradeable_courses

This is a Proof of Concept to validate backend filtering and course categorization logic required for the Subscriber Learner Dashboard.

Implementation Details

• Created a new platform plugin under openedx/plugins/subscriber

• Registered plugin using entry_points and plugin_app configuration

• Implemented API endpoint:

  /api/subscriber/dashboard/courses/

• Fetches learner enrollments using CourseEnrollment model

• Applies subscription catalog and subscriber status logic

• Returns categorized course IDs as JSON response

Example Response

{
"subscription_courses": ["course-v1:edX+DemoX+Demo_Course"],
"upgradeable_courses": [],
"non_upgradeable_courses": []
}

@asharma4-sonata and @jsnwesson Please review my PR whenever you get a chance to look on this. Thank You.

[jsnwesson]

This is the part that we should clarify.

Assume that SUBSCRIPTION_COURSE_IDS will eventually be an API call that we make to the Subscription catalog that another team will create.

From that payload, we'll need to check for each course enrollment:

1. Is the course part of the Subscription catalog? If yes:
   a. Did the user fulfill either enrolling in the course after becoming a Subscriber or upgrading their audited course into their Subscription? (This is likely to mean that in the Enrollments payload we will know if the course is upgraded to a full-access.)
   • If yes to either, then this course falls under subscription_courses.
   • If no to either, then this course falls under upgradeable_courses
2. If no, then the course falls under non_upgradeable_courses.

There's an additional tricky part that I haven't confirmed with Kelly, which is what happens if prior to being a Subscriber the user fully upgraded a course. Where does that course live in these three categories? If the course technically is part of the Subscription catalog, does it go under subscription_courses? If it doesn't, does it go under non_upgradeable_courses even though it indeed is upgraded already? Maybe that 3rd category would be more accurately called non_subscription_courses. I don't know yet.

[pavanhalesh]

Thanks Jason, this is very helpful clarification.

For this POC, I used a hardcoded SUBSCRIPTION_COURSE_IDS list and a simulated user_is_subscriber flag to demonstrate that we can fetch enrollments and categorize courses via the platform plugin.

I agree that in the production implementation, SUBSCRIPTION_COURSE_IDS will be replaced with a Subscription Catalog API call, and categorization will depend on both:

• Whether the course exists in the Subscription catalog
• Whether the enrollment reflects full-access (subscriber enrollment or upgraded course)

Based on your guidance, the intended logic will be:

• If course is in Subscription catalog AND enrollment reflects subscriber/full-access → subscription_courses
• If course is in Subscription catalog BUT enrollment does not reflect subscriber/full-access → upgradeable_courses
• If course is not in Subscription catalog → non_upgradeable_courses

[asharma4-sonata]

Let’s load the test data and run everything through integration tests first. This approach allows the final implementation to move forward without any guesswork and ensures we follow SOLID principles with a clear separation of responsibilities. Relying on hard‑coded values will restrict execution to only one specific flow, which limits flexibility. I understand this is a POC, but we can still put a clean skeleton in place now and expand it as the project evolves. We can also assume that the Swagger API specification will be provided later for us to integrate.

[pavanhalesh]

Thank you for the feedback, @asharma4-sonata .
I’ve updated the implementation to remove hardcoded logic from the core flow and introduced a cleaner service structure with separate functions for fetching subscription catalog courses, checking subscriber status, and retrieving user enrollments. This prepares the plugin for integration testing with real LMS enrollment data and allows us to easily integrate with the future Subscription Catalog API once the Swagger specification is available. Please let me know if any additional adjustments are needed