nahian-19/project_planner

Purpose and entry points

Project Planner is a Django/DRF backend for authenticated project, task, subscription, and notification workflows. HTTP entry is manage.py through Django URL routing at project_planner/urls.py; WSGI and ASGI deployment entry points are project_planner/wsgi.py and project_planner/asgi.py. The versioned REST surface is documented in Project Planner API.yaml.

Application composition

Domain logic is organized as Django apps with the conventional model → serializer → view → URL boundary:

• Users and JWT-based identity/profile lifecycle: apps/users/models.py, apps/users/views.py, apps/users/urls.py.

• Projects, memberships, ownership, invitations, and project querying: apps/projects/models.py, apps/projects/views.py, apps/projects/filters.py.

• Tasks and their project-associated lifecycle/status querying: apps/tasks/models.py, apps/tasks/views.py, apps/tasks/filters.py.

• Administrative project oversight is separately exposed through apps/admins/views.py and apps/admins/urls.py.

Request, authorization, and data flow

Requests enter the root URL configuration, are dispatched to app views, validated/represented by DRF serializers, and persist through Django models. Authentication establishes the user context; shared authorization rules are centralized in core/permissions.py. Project and task filters form the query boundary for list/search-style endpoints. Django admin registrations across app admin.py files provide a separate staff-operated data-management path.

Project collaboration workflow

A project is created or managed by an authorized user, with members represented in the projects domain. Tasks belong to the planning workflow and are listed, updated, and status-tracked through the tasks API. Invitation and registration flows cross domains: user lifecycle handling in apps/users/views.py and reusable email delivery in core/services/mail_service.py support emailed project invitations and subsequent membership completion.

Notifications and realtime delivery

Notifications are a distinct persistence/API domain in apps/notifications/models.py, apps/notifications/views.py, and apps/notifications/urls.py. WebSocket consumers and routing in apps/notifications/consumers.py and apps/notifications/routing.py provide realtime delivery under the ASGI runtime. Notification filtering is isolated at apps/notifications/filters.py.

Subscription and asynchronous processing

Subscription records and HTTP operations reside in apps/subscriptions/models.py, apps/subscriptions/views.py, and apps/subscriptions/signals.py; the README identifies payment integration and Stripe credentials as external dependencies. Celery is configured by project_planner/celery.py; shared background work is located in core/tasks.py. Redis is the material broker/backing service for Celery and the realtime stack, while SQLite is the stated primary database.

Runtime and operational boundaries

project_planner/settings.py is the integration point for Django, DRF, Channels, Redis, Celery, JWT, email, and schema documentation configuration. Run the HTTP service with Django, a Celery worker and beat for asynchronous/scheduled work, and Redis separately. API schema UIs are served under the documented Swagger/ReDoc routes; email delivery requires configured email credentials, and payment operations require Stripe keys.