[META] Ongoing Design and Development of Course Features

[pandalow]

🎯 Overall Goal

Design a flexible and modular Course system that allows content delivery, role-based permissions, and user interaction around course participation and collaboration.

🤔 Current Situation / Problem Addressed

• Currently, EduLite users cannot formally enroll in courses or access structured course materials. This feature addresses that core need for a learning platform.

🧩 Key Components / Scope (High-Level)

Requirements Scope:

The course system should support modular learning content, flexible user-role associations, and collaborative chat spaces for teaching and discussion.

1. Course Content Structure

   • Each course is organized into modular units (or "modules"), with content written in Markdown.
   • Courses and modules support tag-based categorization to enable flexible querying by tag, title, or content.

2. Role-Based Course Participation

   • Courses are linked to users with assigned roles, and each role has a clearly defined permission scope:
     • Teachers can:
       • Create, update, and archive courses
       • Manage course content
       • Invite students, approve student applications and remove students
       • Assign or remove assistants
       • Create and manage course chat rooms
     • Students can:
       • Apply to and register for courses
       • Quit courses voluntarily
       • Apply to become assistants
     • Assistants can:
       • Edit course content (within assigned permission scope)
       • Create and manage chat rooms
       • Quit the assistant role

Database Design

ERD Diagram

Models

1. Course Model

• Fields:
  • title: CharField(max_length=100) — the subject or name of the course, searchable and queryable.
  • outline(optional): TextField(null=True, blank=True) — a brief description of the course.
  • language: CharField(choices=LANGUAGE_CHOICES) — the primary language of the course, shared with the user app.
  • institution: CharField(max_length=100) — acts as a tag for filtering/searching by school or provider.
  • country: CharField(choices=COUNTRY_CHOICES) — course country, reused from user profile settings.
  • start_date: DateTimeField(default=timezone.now) — start time set by the teacher.
  • end_date: DateTimeField(null=True, blank=True) — optional end time; defaults to no limit.
  • is_active: BooleanField(default=False) — marks whether the course is published or available.
  • visibility: CharField(choices=VISIBILITY_CHOICES) — options:
    • public: visible in search and listings
    • restricted: accessible only via course ID or direct link
    • private: only enrolled users can access
  • allow_join_requests: BooleanField(default=True) — whether students can apply to join.

  Note: Course has a one-to-many relationship with CourseModule (not a single ForeignKey).

2. CourseMembership Model

• Fields:
  • user: ForeignKey(User) — links to the participant.
  • course: ForeignKey(Course) — links to the course.
  • role: CharField(choices=ROLE_CHOICES) — defines user role in the course: teacher, student, assistant.

Relationship: This model represents a many-to-many with extra fields (role), between User and Course.

3. CourseModule Model

• Fields:

  • course: ForeignKey(Course) — one-to-many relationship (a course has many modules).
  • content: TextField — Markdown-formatted content representing each module’s learning material.

May also want to add fields like title, order, or estimated_duration for better structure.

4. CourseChatRoom Model

• Fields:
  • course: ForeignKey(Course) — links to the course.
  • chat_room: ForeignKey(ChatRoom) — links to the chat room instance.
  • created_by: ForeignKey(User) — references the creator (teacher/assistant).
  • created_at: DateTimeField(auto_now_add=True) — timestamp when the chat room was created.
  • room_type: CharField(choices=ROOM_TYPE_CHOICES) — indicates the room’s structure (main, sub, private).

This model serves as a many-to-many bridge between Course and ChatRoom, with additional metadata.

Key Components:

1. New Django App (course): Create a app to encapsulate all course-related logic and models.
2. Definition of Data Models for Course System： Design of models to represent courses, course membership, modular content, and course-related chat integration:

• Course: core entity holding course metadata (title, language, visibility, etc.).
• CourseModule: modular content units written in Markdown.
• CourseMembership: relational model connecting users to courses with roles (teacher, student, assistant).
• CourseChatRoom: bridge model connecting a course to its associated chat rooms (main or sub rooms).

3. Implementation of Django REST Framework Serializers
4. API Endpoint Design and Implementation

• GET /api/courses/ – List all visible courses (with filters: title, tag, institution, etc.) (Optional) Supports querying course titles and content via a lightweight search mechanism.
• POST /api/courses/ – Create a course (teacher only)
• GET /api/courses/<id>/ – Retrieve course details and modules
• POST /api/courses/<id>/join/ – Student applies or joins course
• POST /api/courses/<id>/modules/ – Add a new module (teacher or assistant)
• POST /api/courses/<id>/assign-assistant/ – Assign user as assistant
• POST /api/courses/<id>/remove-user/ – Remove student or assistant
• GET /api/courses/<id>/members/ – Get all enrolled users with roles
• GET /api/courses/<id>/chatrooms/ – List associated chatrooms
  Pagination and filtering are applied where necessary to support scalable querying.

4. Permission Rules and Role-Based Access Control
   Each course API enforces permission checks based on the authenticated user’s membership role in the course:

• Teachers can manage all aspects: content, users, assistants, visibility.
• Assistants can help manage modules and create chat rooms.
• Students can view content (if enrolled) and apply to courses.
• Anonymous users can only browse public or restricted courses.

5. Course Service Logic and Utilities

• Utility services handle the automatic creation of course metadata and default modules.
• Signals (optional) can be used to:
  • Notify users when they are invited or accepted into a course.
  • Trigger creation of default main chat room.
• Markdown rendering utility (optional) supports server-side rendering of module content.

✨ Benefits / How This Feature Helps EduLite

• Enables structured and modular learning experiences for students
• Provides educators with tools to create, manage, and deliver course content efficiently
• Facilitates collaboration through integrated chat and assistant roles
• Lays the foundation for a scalable, role-based learning system within EduLite

✅ Success Criteria / Definition of Done (for the Entire Epic)

• Teachers can create, update, and archive courses with core metadata (title, outline, language, institution, etc.).
• Students can browse and filter available courses based on tags, title, and institution, according to course visibility settings.
• Students can apply to or join courses, depending on allow_join_requests and course visibility.
• Teachers can manage membership: approve student applications, assign/remove assistants, remove members.
• Assistants can help manage content and chat rooms, with permissions clearly scoped by role.
• Course-to-ChatRoom integration is functional: each course links to a main chat room and may have multiple subrooms created by teachers/assistants.
• API endpoints are fully implemented and tested for all the above interactions, including permission enforcement.

🔗 Sub-Tasks / Related Issues

(This section should be manually updated in the created issue to link to specific task issues as they are defined. Each sub-task should be its own GitHub Issue.)

• `[COURSES-1]: [COURSES-1] Foundational Setup for the Course System: App, Models, and Choices Architecture #108
• [Task Category 1]: [Specific Task 1.2 Name] (#IssueNumber)
• [Task Category 2]: [Specific Task 2.1 Name] (#IssueNumber)
• (Add more as they are defined...)

💡 Additional Context (Optional)

🛠️ Tech Stack Considerations (Optional)

---

This is a significant feature, and your contribution to any part of it is highly valued! Let's build something great together!

[smattymatty]

Nice, it looks like you've thought of everything we need to get started! Thanks for including a picture of the models too.

I like the flexibility of allowing teachers to keep their classes private, invite only, or public. A lot of differe

I can look into making some sub-tasks for this META task, and I can include them in here.

I have a suggestion for the CourseMembership model, we could add a 'status' field for choices=[('pending', 'Pending Approval'), ('enrolled', 'Enrolled'), ('invited', 'Invited')] to keep track of people who have already been invited, or are already applied.

For Modules, we can start very simple for now just to get going (course chapters, markdown content to read, pictures, etc.) , but later we can make it more complex as we figure out how we want to do

• Assignment
• Quizzes/Exams
• Smart Anti Cheating, etc.
  We can add that stuff later, maybe even in its own app if we decide. Right now, this should be more than good enough to get a foundation going.

Good job!

[johncosta]

Hello - I'd like to work on this issue if its still available.

[pandalow]

Sure, I’ve already completed the serializer and model parts — you can take over building the API view for the course. All the new code has been included in the codebase.

By the way, if you’re creating any new choice or enumeration files, please place them in the main folder instead of subfolders, so they can be reused more easily by others.

Sorry that I haven’t had enough energy to finish the API part recently — I’ve been struggling with job hunting. Thanks for understanding.

Hello - I'd like to work on this issue if its still available.