feat: Add Pagination Support to GET /api/v1/activity-log Endpoint #1197

[Dafinci01]

Description

The current GET /api/v1/activity-logs endpoint returns all activity logs in a single response, which can lead to performance issues and overly large payloads as the number of logs grows. This enhancement introduces pagination support, allowing clients to fetch logs in manageable chunks.

Related Issue (Link to issue ticket)

[Issue #1115](#1115)

Motivation and Context

• Improves performance by reducing response payload size.
• Enhances API usability by providing paginated responses.
• Prevents memory and latency issues with large datasets.

How Has This Been Tested?

Manual API Testing

Default Pagination:

Sent a GET request to /api/v1/activity-logs without any parameters.

Verified that the response included 20 logs (if available) and the correct pagination metadata.

Custom Pagination:

Sent a GET request to /api/v1/activity-logs?page=2&limit=10.

Confirmed that the response included the correct subset of logs corresponding to page 2 and limit 10, along with accurate pagination metadata.

Edge Case Testing:

Tested scenarios such as negative page values, excessively high limits, and requests for pages beyond the available data.

Verified that appropriate validation errors or empty results were returned.

Testing Steps

1. Default Pagination:

   • Send a GET request to /api/v1/activity-logs without any parameters.
   • Verify that the response includes 20 logs (if available) and the correct pagination metadata.

2. Custom Pagination:

   • Send a GET request to /api/v1/activity-logs?page=2&limit=10.

   • Confirm that the response includes the correct subset of logs corresponding to page 2 and limit 10, along with accurate pagination metadata.

Screenshots (if appropriate - Postman, etc):

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

Proposed Solution

The endpoint should support pagination with the following changes:

Query Parameters:

• page (optional, default: 1) - Specifies the page number.
• limit (optional, default: 20) - Specifies the number of logs per page.

Response Structure:

The response should include a pagination object containing:

• page: The current page number.
• limit: The number of logs per page.
• total_items: The total number of activity logs.
• total_pages: The total number of pages based on the limit.

Default Behavior:

• If no parameters are provided, return page 1 with 20 logs.
• Maintain consistency with existing response structures.

Expected JSON Response Format:

{
  "status": "success",
  "status_code": 200,
  "message": "Activity logs retrieved successfully",
  "data": {
    "logs": [ /* array of activity logs */ ],
    "pagination": {
      "page": 1,
      "limit": 20,
      "total_items": 100,
      "total_pages": 5
    }
  }
}

Acceptance Criteria

• The endpoint accepts optional page and limit query parameters.
• Returns the default subset (page 1, 20 logs) when no query parameters are provided.
• Includes a pagination object with page, limit, total_items, and total_pages in the response.
• Maintains existing functionality and adheres to the standard JSON response format.

[phurhard]

Resolve the merge conflict

[phurhard]

Implement the changes requested

[phurhard]

why the repitions??

[phurhard]

Revert this

[phurhard]

just passing the page and page limits doesn't mean it's reflected in the implementation.

[phurhard]

why is this deleted, revert it