Samaneh Hooshmand Modiriat Abresani

The Samaneh Hooshmand Modiriat Abresani is an environment for recording and following up water-supply requests and for operational monitoring of the network, which unifies the link between field crews and headquarters specialists in a single software environment. It is implemented on Node.js and PostgreSQL and offers one shared API to both the field application and the web dashboard. Authentication in the system is token-based, and access to the services is controlled with that token. The main goal is to record requests accurately on site, follow their state through to completion, and provide a live picture of operations for decision-making.

The problem this system solves

In water-supply operations, requests and operational events are usually moved between field crews and headquarters orally or on paper; this practice causes requests to be lost and leaves no clear picture of the state of operations.

By recording a request at the field point itself and transferring it to the central database, the system makes it possible to follow each request from the moment it is logged to completion.

A single data path between the field app and the headquarters dashboard prevents re-entering information and discrepancies between reports.

Users: field crews and headquarters specialists

Users fall into two main groups. The field worker records requests and on-site events and updates their completion state, while the headquarters specialist follows and prioritises requests through the web dashboard.

Token-based authentication ensures that each user reaches the services only with their own credentials.

  • Field worker, who records requests and network events.
  • Headquarters specialist, who follows, refers and prioritises requests.
  • Operations manager, who views the monitoring dashboard and overall status.

Recording and following up water-supply requests

The base unit of data is the water-supply request: each request has a type, a registration time, an extent and a current state, and is followed throughout its life cycle.

Following the state lets the specialist see which stage a request has reached and which requests are still awaiting action.

Recording the time and details of each request makes it possible to review the history and examine the progress of handling.

  • Recording the request type and extent at the moment it is observed in the field.
  • Updating the request state through to completion.
  • Following requests awaiting action by the headquarters specialist.
  • Reviewing request history over a date range.

One shared API and the operational monitoring dashboard

The system architecture rests on one shared API that both the field application and the web dashboard use; the logic of data access is therefore held and maintained in a single place.

The operational monitoring dashboard gives an aggregate picture of requests and their states and helps specialists see the workload and the progress of handling.

Sharing the API makes it simple to add new services or tools without changing the base logic.

  • One access point for the field application and the web dashboard.
  • An aggregate view of request states in the monitoring dashboard.
  • Data-access logic maintained in a single layer.

Data organisation and the database

Data is held in the PostgreSQL database, and the table structure is designed to store requests, their states and user information.

Centralising the database ensures that the field app and the web dashboard work on a single version of the data.

The data structure allows new request types or states to be added without a fundamental redesign.

Token authentication and access control

Authentication in the system is token-based, and every request to a service is verified and controlled with the user’s credentials.

Access control is enforced by user role, so the field worker and the headquarters specialist each reach only the part that concerns them.

This approach makes communication between the field app and the server possible without maintaining heavy sessions.

Deployment and rollout

The system is deployed on the organisation’s server, and the PostgreSQL database and the server-side service are held in that environment.

Rollout begins with defining request types, states and user roles, and the field application and web dashboard are then enabled for users.

Once operation starts, requests are recorded in the field and followed in the dashboard, and the data stays continuously up to date.

Summary

The Samaneh Hooshmand Modiriat Abresani links on-site request recording with headquarters follow-up and operational monitoring and provides a live picture of operations.

Its architecture based on Node.js and PostgreSQL with one shared API makes the system easy to maintain and to extend with new services.

Token authentication and role-based access control regulate access to the data, and deploying on the organisation’s server keeps it under the operator’s control.