Power Awareness Tool

The Power Awareness Tool 2.0 (PAT 2.0) aims to increase accessibility and user engagement by transitioning from an Excel-based tool to a fully digital platform. This initiative will allow a broader audience to leverage the PAT for analyzing and understanding power dynamics within their organizations and partnerships. 

Project Sheet

Build Status Repo Size Languages Issues Last Commit Coverage Status Coverage Status

Name
 Power Awareness Tool
Project Scope
 The Power Awareness Tool 1.0 was launched by Partos in February 2020, as a tool to help make power relations more visible. In 2022, the tool was evaluated, resulting in the improved Power Awareness 2.0 version which serves as the basis for this assignment. The tool gives the different stakeholders the chance to share and monitor their insights on their decision-making practice within their project. It is part of a shared objective of Partos and involved members to actively promote and work to shift power, understand the effects of power dynamics on the decision-making process and create transparency on why, how and by whom decisions are being made. 
Contract Link
Project Dashboard Link
Start Date
End Date
Repository Link
 https://github.com/akvo/partos-pat
Tech Stack

List of technologies used to execute the technical scope of the project:

  • Front-end: JavaScript with React Framework
  • Back-end: Python with Django Framework
  • Testing: Django Test Framework, Jest
  • Coverage: Coveralls
  • Documentation: RTD, dbdocs
  • CI & CD: Github Workflow
  • Hosting: GKE
  • Database: PostgreSQL, Cloud-SQL
  • Storage: Cloud Storage Buckets
Asana Link
 Partos PAT 2.0 Engineering Planning Board
Slack Channel Link proj-partos-tool-tech

Low Level Design

Introduction

About Power Awareness Tool

The Power Awareness Tool 1.0 was launched by Partos in February 2020, as a tool to help make power relations more visible. In 2022, the tool was evaluated, resulting in the improved Power Awareness 2.0 version which serves as the basis for this assignment. The tool gives the different stakeholders the chance to share and monitor their insights on their decision-making practice within their project. It is part of a shared objective of Partos and involved members to actively promote and work to shift power, understand the effects of power dynamics on the decision-making process and create transparency on why, how and by whom decisions are being made. 

The Purpose of Power Awareness Tool

The Power Awareness Tool (PAT) is designed to help stakeholders make power relations within their projects more visible, facilitating transparency in decision-making processes. PAT 2.0 aims to build on the lessons learned from the initial version, offering an improved user experience and more effective insights for stakeholders. By helping users better understand power dynamics and how these affect the decision-making process, PAT promotes more equitable partnerships and empowers stakeholders to take informed action. The digital platform we are developing will bring PAT 2.0 to life in a more accessible and user-friendly format, supporting its core mission.

Key Objectives

  1. Implementing a user-friendly platform: The primary goal is to digitize PAT 2.0, focusing on usability, ease of navigation, and accessibility. This will enable facilitators and participants to interact with the tool in an intuitive way, making it easier to capture, manage, and analyze data related to decision-making processes in their projects.

  2. Core functionality first, with room for future expansion: The platform will begin with essential features to support user needs, but it will also be designed to accommodate future expansion. As users provide feedback, new features and improvements can be added, ensuring the platform remains flexible and evolves with changing requirements.

Functional Overview

Here is a breakdown of the core functionalities that will be implemented in the first version of the digital PAT 2.0 platform:

1. Home Page

2. PAT Application

The core of the digital platform, where facilitators and participants interact with the tool’s decision-making features:

3. Access and Rights Management

Ensuring that data privacy and user access control are handled effectively is critical to maintaining trust and transparency:

4. Statistics and Analytics

The platform will offer built-in statistical tracking features to monitor the effectiveness and usage of the tool over time. This data can be valuable for both the internal development team and stakeholders using PAT:

User Workflow

This section outlines the user journey and interactions within the Power Awareness Tool 2.0 (PAT 2.0). From account creation to managing and participating in sessions, each step of the workflow is designed to be intuitive, ensuring users can easily navigate and use the platform's core features.

1. Create Account

The first step for any user is to create an account, which provides access to the platform and its functionalities. The account creation form includes the following fields:

Once all fields are filled out and validated, the platform will send a verification link to the user's email. After verifying the email, the account is fully activated, and the user is ready to begin using the platform.

2. PAT Dashboard

Once logged in, users will be directed to the PAT Dashboard. From here, they have two main options: Create Session (for facilitators) or Join Session (for participants).

2a. Create Session (For Facilitators)

Facilitators can create a new PAT session by filling in the following fields:

Once the session is created, the platform will generate a unique join code. Facilitators can share this code with participants via email or by copying the code using a Copy Code button on the interface.

2b. Join Session (For Participants)

Participants can join a session by following these steps:

Once this information is submitted, participants can join the session and begin navigating through the different sections of the PAT session.

3. PAT Session Structure

Each PAT session is organized into several sections that guide users through a process of evaluating decision-making power and participation within their project or partnership. The main navigation items for a PAT session include:

  1. Decisions (List of Important Decisions): Participants and facilitators write the list of key decisions made within the project.

  2. Level of Participation (Determine Actual Level of Participation): Users assess and record the actual level of participation by each stakeholder or organization involved.

  3. Actual Participation (Reflect on Actual Level of Participation): Participants reflect on whether the recorded levels of participation were appropriate and fair.

  4. Desired Level of Participation: Users document what they believe should be the ideal or desired level of participation for each stakeholder.

  5. Action for Change: Participants and facilitators suggest and discuss actions that could be taken to shift power dynamics and improve participation equity.

  6. Close PAT Session: Facilitators close the session once all steps have been completed, and final reports are generated.

Each section in the navigation bar includes a status indicator: In Progress – if some data has been entered but the section is incomplete. Not Started – if no data has been entered yet.

3a. Session Interactions

The platform offers different roles and interactions for Facilitators and Participants during a PAT session.

a. As a Facilitator

Facilitators have full control over the session. They can:

Once the facilitator clicks the Publish button, the session is officially marked as complete. Here's what happens after:

  1. Session Becomes Read-Only: After publishing, the session is locked and can no longer be edited by the facilitator or participants. All fields and data become read-only, ensuring that the information recorded during the session remains unchanged and can serve as a permanent record.

  2. Session Moves to the Dashboard: The closed session will appear under a dedicated section on the dashboard labeled Closed Sessions. These sessions are no longer active and serve as an archive of completed analyses and reports. Users can revisit these closed sessions to review the data and insights captured, but they will not be able to modify any of the content.

  3. Access to Reports: Facilitators and participants will still be able to download or view the session’s reports, which summarize the outcomes and key findings. This ensures that the insights gathered from the session can be easily shared with other stakeholders or used in future discussions or evaluations.

The finalization process, marked by clicking the Publish button, transitions the session from an editable, active state to a closed, read-only state. This ensures data integrity and creates a permanent record of the insights gathered during the session. By moving completed sessions to the Closed Sessions list on the dashboard, facilitators and participants can always access past analyses for reference or reporting without risking accidental changes or loss of data.

b. As a Participant

Participants have limited control and can only contribute to certain sections, depending on their role in the project. They can:

4. Users Page

This page is accessible only to admin users and displays user data in a tabular format. Admins can perform the following actions:

5. Statistics Page

This page is accessible only to admin users and displays various statistics related to the system. The following information is provided:

6. FAQs Page

The FAQs page offers a collection of frequently asked questions along with their corresponding answers to assist users in understanding everything they need to know about the Power Awareness Tool.

Architecture

The architecture of the Power Awareness Tool 2.0 (PAT 2.0) is designed to ensure scalability, security, and flexibility while delivering a seamless user experience. The system will follow a modular architecture that separates the front-end, back-end, and data layers, ensuring clear separation of concerns, maintainability, and ease of future enhancements.

The core components of the architecture include the Next.js frontend, the Django backend, and a PostgreSQL database, all orchestrated via Kubernetes for scalability and reliability. Continuous integration and deployment will be managed using GitHub Workflows.

High-Level Architecture Overview

1. Front-end (Next.js)

This is the user-facing layer where participants and facilitators interact with the platform. Next.js (built on React) will be used for rendering user interfaces, routing, and server-side rendering (SSR) to improve performance and SEO (for Home Page).

Components:

2. Back-end (Django)

This is the core of the platform, responsible for handling business logic, validating user input, managing sessions, and interacting with the database. Django will be used to develop the API layer and handle back-end tasks like session management, user roles, and permissions.

Components:

3. Database (PostgreSQL)

To store and manage all data related to users, sessions, organizations, and reports. PostgreSQL, a robust relational database, will be used for data storage.

Data Model:

4. Container Orchestration (Kubernetes)

Kubernetes will be used to deploy and manage the containerized services (Next.js and Django applications). It ensures the platform remains scalable, fault-tolerant, and highly available.

Key Components:

5. CI/CD Pipeline (GitHub Workflows)

Purpose: Continuous integration and deployment will be automated using GitHub Workflows to ensure smooth development and deployment processes.

Workflow:

Security and Stability Considerations

Security is a paramount concern in the architecture of PAT 2.0. Here are the key security measures implemented:

The architecture is built to handle growth and ensure a smooth user experience:

Database Design

The database for the Power Awareness Tool 2.0 (PAT 2.0) will be designed using PostgreSQL as the relational database management system. The schema is designed to efficiently store user data, session details, organizations involved, and various statistics and reports generated by the platform. The following is a breakdown of the key tables that will be used in the database, along with a brief explanation of their fields.

1. Users Table

This table will store information about the users of the platform, including facilitators and participants.

Field Name Data Type Description
id BIGINT (Primary) Unique identifier for each user.
full_name VARCHAR(255) Full name of the user.
country VARCHAR(100) Country of the user’s origin (predefined list).
email VARCHAR(255) Email address (must be unique).
password_hash TEXT Hashed password for security purposes.
verification_code UUID
 For verifying user's email
is_verified BOOLEAN Indicates whether the email is verified (True/False).
is_superuser
 BOOLEAN
 Indicates whether the user has administrative privileges. The default value is False.
created_at TIMESTAMP Timestamp when the account was created.
updated_at TIMESTAMP Timestamp when the account was last updated.

2. Sessions Table

This table stores information about each session, which is created by a facilitator for partnership evaluation or power mapping.

Field Name Data Type Description
id BIGINT (Primary) Unique identifier for each session.
user_id BIGINT (Foreign Key) Refers to the id of the facilitator in the Users table.
session_name VARCHAR(255) Name or title of the session.
countries TEXT (Serialized) List of countries relevant to the session.
purpose ENUM Purpose of the session
date DATE Date when the session is held or started.
context TEXT A description of the session's context.
notes TEXT
 A Notes before closing PAT Session (optional)
summary TEXT
 A Summary before closing PAT Session
join_code VARCHAR(100) Unique code generated for participants to join the session.
is_published BOOLEAN Indicates whether the session is published and closed.
created_at TIMESTAMP Timestamp when the session was created.
updated_at TIMESTAMP Timestamp when the session was last updated.
closed_at TIMESTAMP Timestamp when the session was published/closed.

3. Organizations Table

This table stores information about the organizations involved in each session. Facilitators can add organizations during session creation, and participants must select their organization when joining.

Field Name Data Type Description
id BIGINT (Primary) Unique identifier for each organization.
session_id BIGINT (Foreign Key) Refers to the id of the related session in the Sessions table.
organization_name VARCHAR(255) Full name of the organization.
acronym VARCHAR(50) Acronym or short name of the organization.

4. Participants Table

Field Name Data Type Description
id BIGINT (Primary) Unique identifier for each participant entry.
user_id BIGINT (Foreign Key) Refers to the id of the user in the Users table.
session_id BIGINT (Foreign Key) Refers to the id of the session in the Sessions table.
organization_id BIGINT (Foreign Key) Refers to the id of the organization in the Organizations table.
role
 VARCHAR(100)
 Store the participant's role name when they join the session
joined_at TIMESTAMP Timestamp when the participant joined the session.
session_deleted_at
 DATETIME
 Records the date and time when a session was marked as deleted by the user. The session remains accessible to others even after deletion by the user.

5. Decisions Table

This table will store information about important decisions made during a Partos session. Each decision is linked to a session and has details such as the decision name, agreement status, and optional notes provided by the facilitator or participants.

Field Name Data Type Description
id BIGINT (Primary) Unique identifier for each decision.
session_id BIGINT (Foreign Key) Refers to the id of the related session in the Sessions table.
name VARCHAR(255) The name or description of the decision.
agree BOOLEAN Indicates whether the decision was agreed upon (True/False).
notes TEXT Additional notes or context regarding the decision.
created_at TIMESTAMP Timestamp when the decision was created.
updated_at TIMESTAMP Timestamp when the decision was last updated.

6. Participant Decisions Table

This table will store individual participant evaluations or ratings of decisions made during a session. Each entry links an organization (via organization_id) to a specific decision (via decision_id) and records the organization's score or evaluation of that decision.

Field Name Data Type Description
id BIGINT (Primary) Unique identifier for each participant's decision evaluation.
organization_id BIGINT (Foreign Key) Refers to the id of the participant (user) in the Users table.
decision_id BIGINT (Foreign Key) Refers to the id of the decision in the Decisions table.
score INTEGER The participant's evaluation or rating of the decision (e.g., on a scale of 1-5).
desired
 BOOLEAN
 Indicates whether the score pertains to disagreement discussions. The default value is NULL.
created_at TIMESTAMP Timestamp when the score was recorded.
updated_at TIMESTAMP Timestamp when the score was last updated (if applicable).

7. Participant Comments Table

This table stores individual comments made by participants. Each entry links a user through user_id and a session through session_id.

Field Name Data Type Description
id
 BIGINT (Primary)
 Unique identifier for each comment.
session_Id
 BIGINT (Foreign Key)
 Refers to the id of the related session in the Sessions table.
user_id
 BIGINT (Foreign Key) Refers to the id of the user in the Users table.
comment
 TEXT
 Stores the comment made by a participant related to the session.
created_at
 TIMESTAMP Timestamp when the comment was recorded.
updated_at
 TIMESTAMP Timestamp when the comment was last updated (if applicable).

API Design

The API for the Power Awareness Tool 2.0 platform will enable communication between the frontend (Next.js) and the backend (Django). It will follow RESTful principles, allowing for efficient data manipulation and retrieval for users, sessions, organizations, decisions, and participant decisions. Below, we'll outline the major API endpoints for managing users, sessions, organizations, participants, decisions, and participant decisions. Each endpoint will return or accept data in JSON format.

A. Classes & Utilities

A.1. Custom Pagination Class

Response Structure

{
    "current": <current page number>,
    "total": <total items count>,
    "total_page": <total number of pages>,
    "data": <paginated data>
}

Class Structure

from rest_framework.response import Response
from rest_framework.pagination import PageNumberPagination


class Pagination(PageNumberPagination):
    page_size = 10
    page_size_query_param = "page_size"
    max_page_size = 100

    def get_paginated_response(self, data):
        return Response(
            {
                "current": self.page.number,
                "total": self.page.paginator.count,
                "total_page": self.page.paginator.num_pages,
                "data": data,
            }
        )

    def get_paginated_response_schema(self, schema):
        return {
            "type": "object",
            "properties": {
                "current": {
                    "type": "integer",
                    "example": 123,
                },
                "total": {
                    "type": "integer",
                    "example": 123,
                },
                "total_page": {
                    "type": "integer",
                    "example": 123,
                },
                "data": schema,
            },
        }

1. User API

1.1. Create User (Sign Up)

Register a new user on the platform.

Endpoint: POST /api/v1/register/

Request Body:

{
    "full_name": "John Doe",
    "gender": 2,
    "country": "ID",
    "account_purpose": 1,
    "email": "john.doe@example.com",
    "password": "Test#123",
    "confirm_password": "Test#123",
}

Response: 201 Created on success. A verification email is sent.

{
    "id": 1,
    "full_name": "John Doe",
    "email": "john.doe@example.com",
    "gender": 2,
    "country": "ID",
    "account_purpose": 1,
    "is_superuser": false
}

1.2. Verify User

Verify the user's email using the verification link.

Endpoint: GET /api/v1/verify?code={code}

Response: 200 OK if successful.

{
    "message": "Email verified successfully."
}

1.3. User Login

This API endpoint allows users to log in to the platform using their email and password credentials. Upon successful authentication, a session is established for the user.

Endpoint: POST /api/v1/users/login/ 

Request Body:

{
    "email": "john.doe@example.com",
    "password": "password123"
}

Response: 200 OK on success, with JWT token for session authentication.

{
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
    "expiration_time": "2024-10-22T18:06:11Z",
    "user": {
        "id": 1,
        "full_name": "John Doe",
        "email": "john.doe@example.com",
        "gender": 1,
        "country": "ID",
        "account_purpose": 1,
        "is_superuser": false
    }
}

1.4. User Forgot password

This API endpoint allows users to request a password change. Users can initiate the process by providing their registered email address, and a password reset link or instructions will be sent to them.

Endpoint: POST /api/v1/users/forgot-password/ 

Request Body:

{
    "email": "john.doe@example.com"
}

Response: 200 OK on success

1.5. Verify password code

This API endpoint verifies the token provided during the password reset process. It validates that the token belongs to the correct user who requested the password reset, ensuring the authenticity of the request before proceeding.

Endpoint: GET /api/v1/users/verify-password-code?token=secret

Response: 200 OK on success

{
    "message": "OK"
}

1.6. User Reset Password

This API endpoint allows users to update their old password with a new one. A valid token is required to authorize the password reset, ensuring the request is tied to the correct user.

Endpoint: POST /api/v1/users/reset-password?token=secret 

Request Body:

{
    "password": "NewPass123",
    "confirm_password": "NewPass123"
}

Response: 200 OK on success

{
   "message": "Password reset successfully"
}

2. Session API

2.1. Create Session

This API endpoint allows facilitators to create a new Power Awareness Tool (PAT) session.

Endpoint: POST /api/v1/sessions/

Request Body

{
    "session_name": "Partnership Evaluation - Health Sector",
    "countries": ["NL", "KE"],
    "purpose": 1,
    "date": "2024-09-15",
    "context": "Evaluating the partnership dynamics.",
    "organizations": [
        {"name": "Akvo", "acronym": "AKV"},
        {"name": "Partos", "acronym": "PTS"}
    ]
}

Response: 201 Created on success. Return join code

{
    "id": 101,
    "session_name": "Partnership Evaluation - Health Sector",
    "join_code": "ABCDE12345",
    "is_published": false
}

2.2. Get / Put Session by Session ID

This API endpoint allows users to retrieve or update the details of a specific session using its session_id. Access is restricted to the session owner or participants. If the request comes from a non-owner or non-participant, a "Forbidden" response will be returned.

Endpoint: GET, PUT /api/v1/sessions?id={session_id}

JWT Access: Owner & Participant

Response: 200 OK on success.

{
    "id": 101,
    "session_name": "Partnership Evaluation - Health Sector",
    "facilitator": {
        "id": 1,
        "full_name": "John Doe"
    },
    "organizations": [{
      "id": 1,
      "name": "Akvo"
      "acronym": "AKV"
    },{
      "id": 2,
      "name": "Partos"
      "acronym": "PTS"
    }],
    "countries": ["Netherlands", "Kenya"],
    "purpose": 2,
    "context": "Evaluating the partnership dynamics.",
    "date": "2024-10-22",
    "join_code": "ABCDE12345",
    "is_published": false,
    "notes": "string",
    "summary": "string",
    "created_at": "2024-09-10T12:30:45Z",
    "updated_at": null,
    "closed_at": null
}

2.4 List Session

Filter params

Parameter Type
 Description
published
 BOOLEAN
 Filters sessions based on their status:
- False: Retrieve all active sessions (default).
- True: Retrieve all closed sessions.
role
 ENUM
  Filters the session list based on the user's role:
1 = Facilitated
2 = Participated
search
 STRING
 Filter session by session_name or context.

Retrieve a list of sessions.

Endpoint: GET /api/v1/sessions

JWT Access: Owner & Participant

{
  current: 1,
  total: 1,
  total_page: 1,
  data: [{
    "id": 101,
    "session_name": "Partnership Evaluation - Health Sector",
    "facilitator": {
        "id": 1,
        "full_name": "John Doe"
    },
    "date": "2024-10-22",
    "context": "Evaluating the partnership dynamics.",
    "created_at": "2024-10-22T03:48:43.612Z",
    "updated_at": "2024-10-22T03:48:43.612Z",
    "closed_at": "2024-10-22T03:48:43.612Z",
     "is_owner": true
  }]
]

2.5. Publish Session (Finalise)

Publish and close the session, making it read-only.

Endpoint: PUT /api/v1/sessions?id={session_id}

JWT Access: Owner

Response: 200 OK on success.

{
    "id": 101,
    "session_name": "Partnership Evaluation - Health Sector",
    "is_published": true,
    "closed_at": "2024-09-20T14:45:30Z"
}

3. Participant API

3.1. Get Organisation and Country List by Session Code

Retrieve the organization list on a session.

Endpoint: GET /api/v1/sessions?code={join_code}

Response: 200 OK on Success

{
    "id": 101,
    "session_name": "Partnership Evaluation - Health Sector",
    "organizations": [{
      "id": 1,
      "name": "Akvo"
      "acronym": "AKV"
    },{
      "id": 2,
      "name": "Partos"
      "acronym": "PTS"
    }],
    "join_code": "FG-HIJKL-12345"
}

3.2. Join Session

A participant joins a session by entering a join code.

Endpoint: POST /api/v1/participants/join/

Request Body:

{
    "role": "MnE Manager",
    "session_id": 1,
    "organization_id": 1
}

Response: 201 Created on success.

3.3. List participants

Retrieve the participants list on a session.

Endpoint: GET /api/v1/session/{session_id}/participants

Response: 200 OK on Success

[
  {
    "id": 41,
    "full_name": "Jane Doe",
    "email": "string",
    "role": "IT Support",
    "organization_name": "Akvo Foundation",
    "organization_acronym": "AKVO",
    "organization_id": 111
  },
  {
    "id": 42,
    "full_name": "John Doe",
    "email": "john.doe@example.com",
    "role": "MnE Manager",
    "organization_name": "Partos Global",
    "organization_acronym": "PARTOS",
    "organization_id": 112
  },
]

5. Decision API

5.1. Init Multiple Decisions

Add multiple decisions to a session.

Endpoint: POST /api/v1/decisions/

Request Body:

{
    "session_id": 103,
    "decisions": [
        "Decision on budget allocation",
        "Decision on resource distribution"
    ]
}

Response: 201 Created on success. Returns an array of the created decisions with their id and other relevant details.

[
    {
        "id": 501,
        "session_id": 103,
        "name": "Decision on budget allocation",
        "notes": null,
        "agree": false,
        "created_at": "2024-09-13T10:00:00Z"
    },
    {
        "id": 502,
        "session_id": 103,
        "name": "Decision on resource distribution",
        "notes": null,
        "agree": false,
        "created_at": "2024-09-13T10:05:00Z"
    }
]

5.2. Submit Decision Scores for Multiple Decisions

This API endpoint allows facilitators to submit scores for multiple decisions. Facilitators can provide a score for each organization_id along with a corresponding decision_id. Additionally, this endpoint includes a conditional desired field that flags scores related to disagreement decisions.

Endpoint: POST /api/v1/participant-decisions/

Request Body:

{
  "session_id": 101,
  "scores": [
      {
        "organization_id": 21,
        "decision_id": 1,
        "score": 1,
      },
      {
        "organization_id": 21,
        "decision_id": 1,
        "score": 3,
        desired: true
      },
  ]
}

Response: 201 Created on success.

5.3. Update Decision Scores

This API endpoint allows facilitators to update the score for a specific decision. The id parameter is required to identify the decision being updated. Facilitators can modify the score and other relevant fields as necessary.

Endpoint: PUT /api/v1/participant-decisions/

Request Body:

{
  "session_id": 101,
  "scores": [
      {
        "id": 333,
        "agree": false,
        "notes": "We need to do this and that"
      },
      {
        "id": 334,
        "agree": true,
      },
  ]
}

Response: 200 OK on success.

6. User management API

6.1. List users

This API endpoint retrieves a list of all users. Access is restricted to admin users and requires a valid JWT token for authentication.

Endpoint: GET /api/v1/admin/users 

JWT Access: Admin

Response: 200 OK on Success

{
  "current": 1,
  "total": 50,
  "total_page": 10,
  "data": [
    {
      "id": 111,
      "full_name": "John DOe",
      "email": "user@example.com",
      "gender": 1,
      "country": "ID",
      "account_purpose": 1,
      "is_superuser": false
    }
  ]
}

6.2. Update user role

This API endpoint allows admin users to update a user's role by setting the is_superuser boolean value. The possible values are:

Access requires a valid JWT token for authentication.

Endpoint: PUT /api/v1/admin/user/{id}/

Request Body:

{
    "is_superuser": true
}

Response: 200 OK on success.

6.3. Delete user

This API endpoint allows admin users to delete a specified user from the system. Access requires a valid JWT token for authentication.

Endpoint: DELETE /api/v1/admin/user/{id}/

JWT Access: Admin

Response: 204 No response body on success.

7. Statistics API

7.1. Number of users

This API endpoint returns the total number of users in the system. The data reflects the count from the last 30 days. Access requires a valid JWT token for admin authentication.

Endpoint: GET /api/v1/admin/statistics/users

JWT Access: Admin

Response: 200 OK on Success

{
  "total_users": 34,
  "total_users_last_30_days": 26,
  "total_users_per_account_purpose": [
    {
      "account_purpose": "purposeOfAccount1",
      "total": 4
    },
    {
      "account_purpose": "purposeOfAccount2",
      "total": 8
    },
    {
      "account_purpose": "purposeOfAccount3",
      "total": 4
    }
  ]
}

7.2. Number of completed PAT Sessions

This API endpoint retrieves the total number of completed Power Awareness Tool (PAT) sessions within the last 30 days. Access requires a valid JWT token for admin authentication.

Endpoint: GET /api/v1/admin/sessions/completed

JWT Access: Admin

Response: 200 OK on Success

{
  "total_completed": 31,
  "total_completed_last_30_days": 7
}

7.3 Number of created PAT sessions in last 3 years

This API endpoint returns the total number of PAT sessions created in the last three years. Access requires a valid JWT token for admin authentication.

Endpoint: GET /api/v1/admin/sessions/per-last-3-years

JWT Access: Admin

Response: 200 OK on Success

[
  {
    "total_sessions": [2,2,4,2,2,5,2,1,3,3,1,3],
    "year": 2022
  },
  {
    "total_sessions": [1,1,4,3,2,0,2,4,2,2,7,2],
    "year": 2023
  },
  {
    "total_sessions": [1,5,3,3,2,3,4,5,10,8,3,2],
    "year": 2024
  }
]