📧📱 Implement Email & SMS Notification Service

.github/workflows/ci.yml

@@ -0,0 +1,31 @@
+
+name: CI
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v3
+
+      - name: Set up Python
+        uses: actions/setup-python@v3
+        with:
+          python-version: 3.11
+
+      - name: Install dependencies
+        run: |
+          python -m venv .venv
+          source .venv/bin/activate
+          pip install -r backend/requirements.txt
+
+      - name: Run tests
+        run: |
+          source .venv/bin/activate
+          pytest backend/tests

README.md

@@ -2,68 +2,128 @@
 
 ## Project Summary
 
-LifeLine-ICT is a system for … (brief description: what problem is solved, who uses it, main components: IoT, backend, GIS, frontend, deployment)  
+LifeLine-ICT is a digital infrastructure management platform that supports the
+Uganda University ICT department. The system tracks strategic ICT projects,
+inventory assets, IoT deployments, and the maintenance activities that keep
+digital services reliable for students and researchers. The repository contains
+code for the IoT device layer, the backend APIs, and supporting documentation so
+faculties can adapt the platform to their own campuses.
 
 ### High-Level Architecture
 
-Brief overview of how iot, backend, gis, frontend interact. Maybe include a diagram (link to `docs/architecture.md`).
+The solution comprises five collaborating layers:
+
+- **IoT layer** – ESP32-based sensor nodes send telemetry to a lightweight Flask
+  logger (`iot/logging`).
+- **Backend APIs** – A FastAPI service (`backend/app`) exposes CRUD endpoints for
+  projects, resources, locations, maintenance tickets, and sensor sites.
+- **GIS & Analytics** – Future modules will combine telemetry and asset data to
+  power dashboards and risk assessments.
+- **Frontend** – Web dashboards and mobile apps consume the backend APIs.
+- **Deployment** – Infrastructure-as-code scripts will package the stack for on
+  campus or cloud hosting.
+
+Consult `docs/backend_crud_plan.md` for the architectural rationale that guided
+issue `#5` (CRUD API implementation).
 
 ### Module Overview
 
-- **iot/** – code for sensors, gateways, device firmware  
-- **backend/** – APIs, business logic, data storage  
-- **gis/** – geospatial processing, map generation, spatial analyses  
-- **frontend/** – user interfaces, dashboards, maps  
-- **deployment/** – infrastructure as code, deployment manifests, Docker, etc.  
-- **docs/** – project documentation  
+- `iot/` – Firmware sketches and logging scripts for field sensors.
+- `backend/` – FastAPI application, domain models, services, and tests.
+- `docs/` – Supplemental guides and design notes.
+- Additional directories (frontend, gis, deployment) will be filled as the
+  broader initiative matures.
 
-## Getting Started
+## Backend Service (Issue #5 Deliverable)
 
 ### Prerequisites
 
-List required tools (e.g. Node.js, Python, Docker, etc.)
+- Python 3.11+
+- `pip` or `uv` for dependency management
+- Optional: `uvicorn` CLI for local development
 
-### Local Setup
+### Installation
 
-Steps to clone, install dependencies, run each module (iot, backend, frontend, etc.)
+```bash
+python -m venv .venv
+source .venv/bin/activate
+pip install -r backend/requirements.txt
+```
 
-### Running Tests / Building
+### Running the API
 
-Commands to run tests, linting, build all modules, etc.
+```bash
+uvicorn backend.app.main:app --reload
+```
 
-### Deployment
+The service listens on `http://127.0.0.1:8000` by default. OpenAPI
+documentation is available at `http://127.0.0.1:8000/docs`.
 
-Instructions (or link to docs) to deploy to staging / production environments.
+### Core Endpoints
 
-## Contributing
+| Entity | Base Path | Notes |
+| --- | --- | --- |
+| Projects | `/api/v1/projects` | CRUD with pagination & search |
+| ICT Resources | `/api/v1/resources` | Validates project/location references and enforces ticket rules |
+| Locations | `/api/v1/locations` | CRUD with geo metadata |
+| Maintenance Tickets | `/api/v1/maintenance-tickets` | Requires resolution metadata when closing a ticket |
+| Sensor Sites | `/api/v1/sensor-sites` | Links IoT deployments to resources, projects, and locations |
 
-We welcome contributions! Please follow these guidelines:
+Each list endpoint accepts `limit`, `offset`, and `search` query parameters and
+returns pagination metadata to keep API consumers informed.
 
-1. Fork the repository  
-2. Create a feature branch: `git checkout -b feature/your-feature`  
-3. Commit changes with clear, descriptive messages  
-4. Write tests where applicable  
-5. Ensure linting and tests pass  
-6. Submit a pull request  
+### Running Tests
 
-### Coding Standards
+```bash
+pytest backend/tests
+```
 
-- Language(s) used (e.g. Python, JavaScript, etc.)  
-- Style/lint rules (e.g. `eslint`, `flake8`, etc.)  
-- Commit message style (e.g. Conventional Commits)  
+The suite provisions an in-memory SQLite database and covers both service-level
+rules (such as blocking resource deletion while tickets remain open) and API
+contracts.
 
-### Issue / PR Workflow
+### Database Migrations
 
-- Create or reference an issue before starting major work  
-- Keep pull requests small and focused  
-- Use descriptive titles and references to issues  
-- Request reviews, respond to feedback  
+This project uses [Alembic](https://alembic.sqlalchemy.org/en/latest/) for database migrations.
 
-## License
+To create a new migration, run:
+
+```bash
+alembic revision --autogenerate -m "<migration_message>"
+```
+
+To apply migrations to the database, run:
+
+```bash
+alembic upgrade head
+```
+
+### Data Model Highlights
 
-State your license (MIT, Apache, etc.).
+The backend models capture the following relationships:
+
+- Projects aggregate ICT resources and sensor sites.
+- Resources optionally link to projects and locations, and can host sensor
+  deployments.
+- Maintenance tickets belong to resources and require closure notes when marked
+  resolved.
+
+Consult the service-layer docstrings for detailed business rules and
+institutional context.
+
+## Contributing
+
+1. Create an issue or pick an existing one (see `issues.md`).
+2. Branch from `main`: `git checkout -b feature/your-feature`.
+3. Follow the layered structure (`api`, `services`, `repositories`, `models`) to
+   keep contributions organised.
+4. Write tests and run `pytest backend/tests` before opening a pull request.
+5. Document behaviour changes in code docstrings or the project docs.
+
+## License
 
-## Contact / Maintainers
+Pending institutional review.
 
-List maintainers, contact paths, etc.
+## Maintainers
 
+- ICT Directorate, Uganda University – `ict-support@lifeline.example.edu`

backend/.env.example

@@ -0,0 +1,6 @@
+# Default configuration for local development.
+LIFELINE_DATABASE_URL=sqlite+aiosqlite:///./lifeline.db
+LIFELINE_API_VERSION=0.1.0
+LIFELINE_CONTACT_EMAIL=ict-support@lifeline.example.edu
+LIFELINE_PAGINATION_DEFAULT_LIMIT=20
+LIFELINE_PAGINATION_MAX_LIMIT=100