kevinvargis/bottled-water-delivery-management-system

Purpose and topology

This is a packaged-drinking-water delivery-management system with three deployable parts: a React web portal for company, manager, supervisor, and customer roles; an Expo/React Native delivery-team app; and a Node/Express API backed by modeled persistence. The root README describes the operational workflow; source is split under src/Web-App, src/App, and src/server.

Entry points and runtimes

• Web client: Create React App bootstrap at src/Web-App/src/index.js, application routing/composition in src/Web-App/src/App.js.

• Mobile client: Expo entry component src/App/App.js; screen-based React Native UI under src/App/src/screens.

• Backend: Node/Express process starts at src/server/server.js.

• Dependency manifests exist separately at src/Web-App/package.json, src/App/package.json, and src/server/package.json, indicating independently runnable frontend, mobile, and API projects.

Identity, roles, and access boundary

The system’s core hierarchy is company → managers → supervisors → customers/delivery staff. User/domain representation is centered in src/server/models/User.js, role-specific models such as src/server/models/Company.js and src/server/models/Supervisor.js, and user endpoints in src/server/routes/api/users.js.

Web authentication state is managed through Redux-like action/reducer/store layers: src/Web-App/src/actions/authActions.js, src/Web-App/src/reducers/authReducer.js, and src/Web-App/src/store.js. Protected web access is enforced at src/Web-App/src/components/private-route/PrivateRoute.js; bearer-token attachment is isolated in src/Web-App/src/utils/setAuthToken.js. Server authentication configuration is represented by src/server/config/passport.js.

Administrative web workflows

Role-specific web areas partition management responsibilities:

• Company creates managers and views its dashboard: src/Web-App/src/components/company/CreateManager.js, src/Web-App/src/components/company/Dashboard.js.

• Managers provision operational resources and staff—customers, drivers, delivery boys, supervisors, vehicles—through src/Web-App/src/components/manager (for example CreateCustomer.js, CreateVehicle.js).

• Supervisors create/assign routes and inspect inventory via src/Web-App/src/components/supervisor/CreateRoute.js, AssignRoute.js, and Inventory.js.

• Customers request cans, submit complaints, view subscriptions/QR codes through src/Web-App/src/components/customer/RequestCans.js, RegisterComplaint.js, and ViewQr.js.

Delivery execution and mobile flow

The Expo app serves delivery personnel rather than office roles. Its principal stages are sign-in, attendance/team participation, trip selection/viewing, QR scanning, delivery progress, and profile: src/App/src/screens/SignInScreen.js, AttendanceScreen.js, TripScreen.js, ScanScreen.js, and ProgressScreen.js. Shared mobile components include trip switching and delivery-card presentation in src/App/src/components/SwitchTripView.js and DeliScreenCard.js.

Operationally, driver and vehicle QR pairing creates a daily trip; delivery staff join a vehicle/trip; the team scans a customer QR and records filled-can delivery, empty-can pickup, and damage. This client workflow is a boundary to server-side trip, delivery, vehicle, and customer records.

Operational domain and persistence model

Mongoose-style server models define the system of record for fleet and fulfillment: src/server/models/Vehicle.js, src/server/models/Route.js, src/server/models/Trip.js, src/server/models/Deliveries.js, and src/server/models/Inventory.js. Trip lifecycle distinctions are explicitly modeled in src/server/models/Initialtrip.js and src/server/models/Intermediatetrip.js, likely supporting vehicle/team assignment changes during a day. Complaints and customer subscriptions/orders are represented by src/server/models/Complaint.js and src/server/models/Kharidaar.js.

API boundary and input control

REST endpoints are organized by principal actor at src/server/routes/api/customers.js, src/server/routes/api/drivers.js, src/server/routes/api/managers.js, src/server/routes/api/supervisors.js, and src/server/routes/api/boys.js. Validation is separated before domain handling, notably src/server/validation/login.js, src/server/validation/routecreation.js, and src/server/validation/inventoryupdate.js. Credentials/configuration are isolated in src/server/config/keys.js; its contents and the actual database/provider are not visible from the supplied tree.