ashraf1600/cox-s-bazar-student-forum-cuet

1. Repository shape

- This is a single Django monolith with one business app, core, plus the project package csf_cuet.

- manage.py is the entry point; csf_cuet/settings.py, urls.py, wsgi.py, and asgi.py define runtime wiring.

2. Main runtime boundary

- The app follows the standard Django request path: browser/client → project URL router → core.views → core.models / forms → HTML templates.

- core/urls.py likely contains all feature routes, while csf_cuet/urls.py mounts the app and Django admin.

3. Primary business app: core

- All domain logic lives in core, including models, forms, views, admin registration, and app-specific templates/static assets.

- This suggests a tightly coupled but straightforward architecture: one codebase, one database, one web UI.

4. Domain subsystems

- The README and templates indicate several feature areas:

- User/profile management: registration, login, profile edit/update, profile photos, approval workflow.

- Community content: posts, likes/comments, inbox/messages, member profiles.

- Announcements: public/community announcements and homepage highlights.

- Events: event listing and event detail pages.

- Committee and directory: committee member pages, designation/department-based organization, member directory.

- These are likely represented as separate Django models inside core.models and rendered through dedicated views/templates.

5. Admin and moderation boundary

- Django Admin is a major operational surface for content moderation and approval.

- core/admin.py plus the populated staticfiles/jazzmin directory indicate a customized admin experience using Jazzmin.

- Admin appears to be the control plane for user approvals, announcements, events, and structural content such as departments/designations.

6. Data model and persistence

- Persistent storage is Django ORM-backed.

- Development uses db.sqlite3; migrations in core/migrations show the schema evolved over time, including user fields, departments, announcements, and post/message changes.

- media/ stores uploaded user and content images; static files are separated under core/static and compiled into staticfiles/.

7. Template-driven presentation

- Rendering is server-side with Django templates under core/templates/core.

- Pages include homepage, about, dashboard, login/register, profile views/edits, announcements, events, committee, directory, inbox, and message detail.

- core/static/core/css/style.css and js/main.js provide app-specific styling and client-side behavior.

8. Authentication and authorization

- The project uses Django’s authentication system with a custom user model.

- Access is role-sensitive: public pages, authenticated member features, and admin-only moderation/management paths are distinct concerns.

- The “admin approval system” implies a post-registration gating step before full access.

9. Operational/deployment layer

- requirements.txt, runtime.txt, and build.sh indicate deployment on a managed Python hosting platform, consistent with Render.

- staticfiles/ is the collected static output used in production; media/ is the upload destination.

- csf_cuet/asgi.py and wsgi.py show the app can be served under standard Django web servers.

10. Architecture summary for a diagram

- Draw one central Django web application with core as the only feature app.

- Connect it to:

- a browser/UI layer served by Django templates,

- a database via the ORM,

- a media storage area for uploads,

- a static assets pipeline for CSS/JS/images,

- and the Django admin as the moderation/administration interface.

- The key architectural theme is a server-rendered community portal with admin-managed content and member profiles, not a distributed service system.