# samarth-p/college-erp architecture

> Architecture diagram of the GitHub repository samarth-p/college-erp, generated by GitDiagram from its file tree, README and a sample of source files (last updated 2026-06-30). It is an AI-made overview: check details against the source.

- Interactive diagram: https://gitdiagram.com/samarth-p/college-erp
- Repository: https://github.com/samarth-p/college-erp

## Overview

1. **System shape**
   - This is a monolithic **Django** application called **CollegeERP** for college management.
   - The repo contains one Django project package, **CollegeERP**, and two main apps: **info** and **apis**.
   - Persistence is local via **SQLite** (`db.sqlite3`), so the architecture is classic Django MVC/MVT with server-rendered pages plus an API layer.

2. **Primary user-facing subsystems**
   - The application is split around two roles: **students** and **teachers**, with an **admin** role handled by Django admin.
   - The README and template names show the main business features are **attendance**, **marks**, **timetable**, and basic academic/user management.

3. **Django project boundary**
   - `CollegeERP/settings.py`, `urls.py`, and `wsgi.py` define the global runtime configuration and request routing.
   - `CollegeERP/urls.py` is the top-level dispatcher that likely mounts the `info` app routes and the admin site, and possibly the `apis` routes.
   - `manage.py` is the standard entrypoint for local development and management commands.

4. **Core business app: `info`**
   - `info` is the main application containing most domain logic, templates, static assets, and model migrations.
   - Its templates show distinct screens for:
     - login/logout and homepage
     - student pages
     - teacher pages
     - attendance detail and editing
     - marks entry/listing
     - timetable views
     - admin-facing pages
   - This app is likely the center of the UI and workflow orchestration.

5. **Domain model and data layer**
   - `info/models.py` plus many migrations indicate the data model is central and has evolved over time.
   - Based on filenames and README, core entities likely include **students, teachers, departments, courses, classes, attendance, marks, timetables, and attendance ranges**.
   - The database is managed through Django ORM; the admin page is used to create and edit these records.

6. **Authentication and role-based access**
   - The README says the **login page is common for students and teachers**, with usernames based on names and a shared default password.
   - This implies role-based behavior after login: the same authentication entrypoint routes users to different dashboards or views depending on whether they are a student or teacher.
   - Django admin is a separate privileged access path for managing master data and operational records.

7. **Teacher workflow**
   - Teacher-specific templates such as `t_homepage.html`, `t_students.html`, `t_marks_entry.html`, `t_attendance.html`, and `t_timetable.html` suggest teachers can:
     - view assigned classes/students
     - record or edit marks
     - manage attendance
     - inspect timetables
     - generate reports or detail pages
   - Teacher pages appear to be the operational side of the system where data is entered and updated.

8. **Student workflow**
   - Student-facing templates such as `homepage.html`, `attendance.html`, `marks_list.html`, `timetable.html`, and `att_detail.html` suggest students can:
     - view attendance status
     - view marks
     - see timetable and class-related information
     - access summary/detail pages rather than edit data
   - This is a read-oriented layer over the same underlying academic records.

9. **Admin and maintenance workflow**
   - Django admin is used to maintain tables such as **Students, Teachers, Departments, Courses, Classes**, and related objects.
   - There is a custom admin template under `info/templates/admin/attendance/attendance_change_list.html`, which matches the README’s note about resetting attendance time ranges.
   - That reset feature indicates an admin-level maintenance workflow that can regenerate attendance records for a specified date range.

10. **API subsystem**
   - The `apis` app contains `serializers.py`, `views.py`, and `urls.py`, which suggests a separate **REST-style API layer**, likely built with Django REST Framework or a similar serialization pattern.
   - This layer probably exposes selected model data for programmatic access, distinct from the HTML template-driven UI in `info`.
   - In the architecture diagram, this should be shown as a parallel interface into the same ORM/database, not a separate backend.

11. **Presentation layer and static assets**
   - `info/static` contains Bootstrap-based assets and dashboard styling (`sb-admin.css`, JS demo charts, homepage styles).
   - The UI is server-rendered via Django templates, with static assets providing layout, navigation, charts, and admin-like dashboard visuals.
   - The many templates indicate page-specific rendering rather than a single-page frontend.

12. **Request/data flow**
   - Browser request → Django URL routing → app views (`info` or `apis`) → ORM models → SQLite database.
   - For HTML pages, views render templates with model data.
   - For API endpoints, views likely return serialized data instead of HTML.
   - Django admin bypasses most custom UI and directly manages models through the admin framework.

13. **Operational characteristics**
   - The app is designed for **local or small-deployment use**: single Django process, embedded SQLite database, and static asset serving from the project tree.
   - `requirements.txt` and the README’s `runserver` instructions reinforce that this is a straightforward Django deployment, not a distributed system.

14. **Documentation and legacy artifacts**
   - The included PDFs (`DBMS report.pdf`, `SE report final.pdf`) are supporting documentation, not part of runtime architecture.
   - The repo’s many migrations show the schema has accumulated features over time, especially around attendance and teacher/user relationships.

15. **What to show in an architecture diagram**
   - Put **Django project shell** at the top.
   - Show **three external entry points**: browser users (students/teachers), Django admin, and API clients.
   - Under that, show the **info app** as the main business/UI layer, **apis app** as the programmatic access layer, and the **SQLite database** as the shared persistence layer.
   - Include **static assets/templates** as the presentation resources attached to `info`, since that app owns most of the rendered pages.

Main entry points: [`info/models.py`](https://github.com/samarth-p/college-erp/blob/master/info/models.py) (Info models), [`info/apps.py`](https://github.com/samarth-p/college-erp/blob/master/info/apps.py) (Info app), [`CollegeERP/urls.py`](https://github.com/samarth-p/college-erp/blob/master/CollegeERP/urls.py) (Root URLs), [`CollegeERP/settings.py`](https://github.com/samarth-p/college-erp/blob/master/CollegeERP/settings.py) (Settings)

## Diagram (Mermaid)

```mermaid
flowchart TD

subgraph group_entrypoints["Entry points"]
  node_users(("Students/Teachers<br/>browser users"))
  node_admin(("Django Admin<br/>admin console"))
  node_api_clients(("API Clients<br/>programmatic clients"))
end

subgraph group_django["Django project"]
  node_manage_py["manage.py<br/>Django entrypoint<br/>[manage.py]"]
  node_project_urls["Root URLs<br/>routing<br/>[urls.py]"]
  node_settings["Settings<br/>configuration<br/>[settings.py]"]
  node_wsgi["WSGI<br/>runtime entrypoint<br/>[wsgi.py]"]
end

subgraph group_apps["Applications"]
  node_info_app["Info app<br/>ui/domain app<br/>[apps.py]"]
  node_info_views["Info views<br/>HTML views<br/>[views.py]"]
  node_info_models["Info models<br/>domain models<br/>[models.py]"]
  node_info_templates["Info templates<br/>server templates"]
  node_info_static["Static assets<br/>frontend assets"]
  node_info_admin_tpl["Admin template<br/>admin override"]
  node_apis_app["APIs app<br/>api layer<br/>[apps.py]"]
  node_api_views["API views<br/>api handlers<br/>[views.py]"]
  node_serializers["Serializers<br/>data marshalling<br/>[serializers.py]"]
  node_api_urls["API URLs<br/>routing<br/>[urls.py]"]
  node_info_admin["Info admin<br/>model admin<br/>[admin.py]"]
  node_apis_admin["APIs admin<br/>model admin<br/>[admin.py]"]
end

subgraph group_data["Data layer"]
  node_models_db[("SQLite DB<br/>persistent store<br/>[db.sqlite3]")]
end

node_users -->|"HTTP requests"| node_project_urls
node_admin -->|"admin requests"| node_project_urls
node_api_clients -->|"API requests"| node_api_urls
node_manage_py -->|"loads"| node_settings
node_settings -->|"installs"| node_info_app
node_settings -->|"installs"| node_apis_app
node_project_urls -->|"dispatches to"| node_info_views
node_project_urls -->|"dispatches to"| node_api_urls
node_info_app -->|"contains"| node_info_views
node_info_app -->|"contains"| node_info_models
node_info_app -->|"renders"| node_info_templates
node_info_app -->|"serves assets"| node_info_static
node_info_views -->|"queries"| node_info_models
node_info_views -->|"renders"| node_info_templates
node_info_models -->|"persists to"| node_models_db
node_api_views -->|"uses"| node_serializers
node_api_views -->|"reads/writes"| node_info_models
node_serializers -->|"maps"| node_info_models
node_api_urls -->|"routes to"| node_api_views
node_info_admin -->|"administers"| node_info_models
node_apis_admin -->|"administers"| node_apis_app
node_info_admin_tpl -->|"customizes"| node_info_admin
node_admin -->|"uses"| node_info_admin_tpl
node_wsgi -->|"boots with"| node_settings

click node_manage_py "https://github.com/samarth-p/college-erp/blob/master/manage.py"
click node_project_urls "https://github.com/samarth-p/college-erp/blob/master/CollegeERP/urls.py"
click node_settings "https://github.com/samarth-p/college-erp/blob/master/CollegeERP/settings.py"
click node_wsgi "https://github.com/samarth-p/college-erp/blob/master/CollegeERP/wsgi.py"
click node_info_app "https://github.com/samarth-p/college-erp/blob/master/info/apps.py"
click node_info_views "https://github.com/samarth-p/college-erp/blob/master/info/views.py"
click node_info_models "https://github.com/samarth-p/college-erp/blob/master/info/models.py"
click node_info_templates "https://github.com/samarth-p/college-erp/tree/master/info/templates"
click node_info_static "https://github.com/samarth-p/college-erp/tree/master/info/static"
click node_info_admin_tpl "https://github.com/samarth-p/college-erp/blob/master/info/templates/admin/attendance/attendance_change_list.html"
click node_apis_app "https://github.com/samarth-p/college-erp/blob/master/apis/apps.py"
click node_api_views "https://github.com/samarth-p/college-erp/blob/master/apis/views.py"
click node_serializers "https://github.com/samarth-p/college-erp/blob/master/apis/serializers.py"
click node_api_urls "https://github.com/samarth-p/college-erp/blob/master/apis/urls.py"
click node_info_admin "https://github.com/samarth-p/college-erp/blob/master/info/admin.py"
click node_apis_admin "https://github.com/samarth-p/college-erp/blob/master/apis/admin.py"
click node_models_db "https://github.com/samarth-p/college-erp/blob/master/db.sqlite3"

classDef toneNeutral fill:#f8fafc,stroke:#334155,stroke-width:1.5px,color:#0f172a
classDef toneBlue fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#172554
classDef toneAmber fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#78350f
classDef toneMint fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px,color:#14532d
classDef toneRose fill:#ffe4e6,stroke:#e11d48,stroke-width:1.5px,color:#881337
classDef toneIndigo fill:#e0e7ff,stroke:#4f46e5,stroke-width:1.5px,color:#312e81
classDef toneTeal fill:#ccfbf1,stroke:#0f766e,stroke-width:1.5px,color:#134e4a
class node_users,node_admin,node_api_clients toneBlue
class node_manage_py,node_project_urls,node_settings,node_wsgi toneAmber
class node_info_app,node_info_views,node_info_models,node_info_templates,node_info_static,node_info_admin_tpl,node_apis_app,node_api_views,node_serializers,node_api_urls,node_info_admin,node_apis_admin toneMint
class node_models_db toneRose
```

## Components

### Entry points

Ways requests enter the system

- **Students/Teachers**: browser users · Primary human users using the web UI
- **Django Admin**: admin console · Privileged maintenance and data management access
- **API Clients**: programmatic clients · Consumers of the REST-style API layer

### Django project

Project-level routing and runtime configuration

- [manage.py](https://github.com/samarth-p/college-erp/blob/master/manage.py): Django entrypoint · Command-line entry for development and management tasks · `manage.py`
- [Root URLs](https://github.com/samarth-p/college-erp/blob/master/CollegeERP/urls.py): routing · Top-level URL dispatcher for the project · `CollegeERP/urls.py`
- [Settings](https://github.com/samarth-p/college-erp/blob/master/CollegeERP/settings.py): configuration · Global Django settings and app wiring · `CollegeERP/settings.py`
- [WSGI](https://github.com/samarth-p/college-erp/blob/master/CollegeERP/wsgi.py): runtime entrypoint · Deployment interface for the Django application · `CollegeERP/wsgi.py`

### Applications

Main Django apps and their presentation resources

- [Info app](https://github.com/samarth-p/college-erp/blob/master/info/apps.py): ui/domain app · Main business app for academic workflows and server-rendered pages · `info/apps.py`
- [Info views](https://github.com/samarth-p/college-erp/blob/master/info/views.py): HTML views · Request handlers for login, dashboards, attendance, marks, and timetable pages · `info/views.py`
- [Info models](https://github.com/samarth-p/college-erp/blob/master/info/models.py): domain models · Core ORM schema for students, teachers, attendance, marks, classes, and timetables · `info/models.py`
- [Info templates](https://github.com/samarth-p/college-erp/tree/master/info/templates): server templates · HTML pages for student, teacher, and admin-facing screens · `info/templates`
- [Static assets](https://github.com/samarth-p/college-erp/tree/master/info/static): frontend assets · Bootstrap styling, scripts, and page assets for the rendered UI · `info/static`
- [Admin template](https://github.com/samarth-p/college-erp/blob/master/info/templates/admin/attendance/attendance_change_list.html): admin override · Custom admin page for attendance maintenance · `info/templates/admin/attendance/attendance_change_list.html`
- [APIs app](https://github.com/samarth-p/college-erp/blob/master/apis/apps.py): api layer · Separate application exposing serialized data endpoints · `apis/apps.py`
- [API views](https://github.com/samarth-p/college-erp/blob/master/apis/views.py): api handlers · Endpoints returning serialized responses · `apis/views.py`
- [Serializers](https://github.com/samarth-p/college-erp/blob/master/apis/serializers.py): data marshalling · Transforms ORM objects to and from API payloads · `apis/serializers.py`
- [API URLs](https://github.com/samarth-p/college-erp/blob/master/apis/urls.py): routing · URL routes for the programmatic interface · `apis/urls.py`
- [Info admin](https://github.com/samarth-p/college-erp/blob/master/info/admin.py): model admin · Admin registrations for managing core academic records · `info/admin.py`
- [APIs admin](https://github.com/samarth-p/college-erp/blob/master/apis/admin.py): model admin · Admin registrations for API app models · `apis/admin.py`

### Data layer

Shared persistence and model schema

- [SQLite DB](https://github.com/samarth-p/college-erp/blob/master/db.sqlite3): persistent store · Local SQLite database backing the Django ORM · `db.sqlite3`

## Connections

- Students/Teachers → Root URLs: HTTP requests · Browser users reach the application through the root router
- Django Admin → Root URLs: admin requests · Administrative access is routed through Django's admin path
- API Clients → API URLs: API requests · Programmatic consumers reach the dedicated API routes
- manage.py → Settings: loads · Management commands bootstrap the Django settings
- Settings → Info app: installs · Project settings register the main business app
- Settings → APIs app: installs · Project settings register the API app
- Root URLs → Info views: dispatches to · Top-level URL routing sends browser traffic to the info app views
- Root URLs → API URLs: dispatches to · Top-level URL routing includes the API routes
- Info app → Info views: contains · The info app implements its page handlers in views
- Info app → Info models: contains · The info app owns the main domain schema
- Info app → Info templates: renders · HTML responses are composed from templates
- Info app → Static assets: serves assets · Presentation assets support the server-rendered UI
- Info views → Info models: queries · Views read and update domain records through the ORM
- Info views → Info templates: renders · Page handlers produce HTML using templates
- Info models → SQLite DB: persists to · Domain entities are stored in the shared SQLite database
- API views → Serializers: uses · API endpoints serialize ORM objects for responses
- API views → Info models: reads/writes · The API layer shares the same underlying domain models
- Serializers → Info models: maps · Serializers translate core models to API payloads
- API URLs → API views: routes to · API routes map onto endpoint handlers
- Info admin → Info models: administers · Django admin manages the main academic records
- APIs admin → APIs app: administers · Django admin also registers API app models when present
- Admin template → Info admin: customizes · The attendance admin view is customized for maintenance flows
- Django Admin → Admin template: uses · Admin users access the attendance change-list customization
- WSGI → Settings: boots with · Deployment startup uses the project configuration