[Feature] Subject Categories Hardcoded - No Dynamic Subject Management

[anshul23102]

Description

Subject categories are hardcoded in the application. Adding new subjects requires code changes and redeployment. No dynamic subject management system exists.

Steps to Reproduce

1. User wants to add custom subject not in predefined list
2. Check available subjects
3. Custom subject not present
4. Administrator must modify code
5. Redeployment required for change

Environment Information

• Categories: Hardcoded array in JavaScript
• Configuration: No database table
• Admin interface: None
• Flexibility: Minimal

Expected Behavior

• Subjects stored in database
• Admin interface to manage subjects
• Users can create custom subjects
• Changes take effect immediately without redeployment

Actual Behavior

• Subjects hardcoded
• Adding subjects requires code changes
• Redeployment necessary
• No admin interface

Code Reference

• File: src/constants/subjects.js
• Variable: STUDY_SUBJECTS - hardcoded array
• Missing: Database schema for subjects
• Missing: Admin management interface

Additional Context

This is a Level 3 maintainability issue. Fix requires:

• Creating subjects table in database
• Building admin interface
• Loading subjects dynamically
• Caching with invalidation

Suggested Labels

feature-request, maintainability, configuration, flexibility, scalability

[rutul2006]

Hey @anshul23102 and the GSSoC Team!

I’d like to work on this issue as a part of GSSoC! This is a crucial maintainability and scalability enhancement that will eliminate unnecessary redeployments and provide greater flexibility for both admins and users.

Why this matters:

• Reduced Developer Overhead: Admins can add, edit, or remove subjects without requiring code changes or redeployments.
• Enhanced User Experience: Users can create and use custom subjects that align with their unique study needs, rather than being limited to a predefined list.
• Improved Scalability: Storing subjects in the database lays the groundwork for future features like subject-based analytics, filtering, and personalized reporting.
• Better Maintainability: Separating configuration from code follows best practices and makes the application easier to scale in the long run.

Proposed Solution:

• Database Schema: Create a subjects table with essential fields like id, name, slug, color, is_custom, is_active, created_by, and timestamps. Include a seed script to migrate existing hardcoded subjects.
• API Endpoints: Develop secure CRUD endpoints for subject management, with proper validation and role-based authorization (admin-only for create, update, and delete).
• Dynamic Subject Loading: Refactor src/constants/subjects.js and all components using it to fetch subjects dynamically via API, implementing client-side caching (e.g., React Query or SWR) with proper invalidation on updates.
• Admin Management Interface: Build a responsive admin dashboard section to add, edit, and deactivate subjects. Include duplicate prevention, confirmation modals, and clear error handling.
• Fallback & Migration: Ensure graceful fallback to default subjects if the API fails and provide a migration script for a seamless transition.
• Testing: Add unit and integration tests for the API endpoints and admin UI to maintain reliability.

I'd be happy to discuss the preferred database structure, authorization approach, or UI design before I get started!

Could you please assign this issue to me? I'm excited to contribute to this impactful enhancement!

Thank you!