fix: sort on get all jobs

[nitrosx]

Description

This PR implement and fix the sorting of jobs when retrieving a number of jobs using /api/v4/jobs. It also improves the building process for the mongo pipeline used to retrieve the jobs in the jobs service.

Motivation

Working on an ESS specific task, I realized that the jobs were returned in the wrong order when requesting them from the most recent to the oldest. The Filter passed to the GET /api/v4/jobs is:

{
   "where": {
      "type": "embargo_period",
      "statusCode": "jobSubmitted"
    },
    "fields":["createdAt"],
    "limits": {
      "limit": 10,
      "skip": 0,
      "sort": {
        "createdAt": "desc"
      }
    }
  }

Fixes

• fixed job service to correctly use the sort in the mongo pipeline

Changes:

• refactored casl ability function that check access to jobs, so it does not add unnecessary stages to the mongo pipeline

Tests included

• Included for each change/fix?
• Passing?

Documentation

• swagger documentation updated (required for API changes)
• official documentation updated

official documentation info

Summary by Sourcery

Fix job listing sort behavior and refine MongoDB query construction for job access control and retrieval.

Bug Fixes:

• Ensure job retrieval applies the requested sort, limit, and skip correctly when building the MongoDB aggregation pipeline.

Enhancements:

• Simplify and optimize the jobs access MongoDB query by filtering out impossible conditions, handling unrestricted access, and avoiding unnecessary $or and $match stages.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The detection of "impossible" access queries via JSON.stringify(q) === JSON.stringify({ $expr: { $eq: [0, 1] }}) is brittle and hard to read; consider centralizing this sentinel expression in a shared constant or helper and comparing structurally instead of via stringification.
• In jobsMongoQueryReadAccess, the different return shapes ({}, the $expr impossible match, single query, $or array) are quite implicit; extracting small helpers (e.g. hasUnrestrictedAccess, hasNoAccess) would make the control flow and intent clearer.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The detection of "impossible" access queries via `JSON.stringify(q) === JSON.stringify({ $expr: { $eq: [0, 1] }})` is brittle and hard to read; consider centralizing this sentinel expression in a shared constant or helper and comparing structurally instead of via stringification.
- In `jobsMongoQueryReadAccess`, the different return shapes (`{}`, the `$expr` impossible match, single query, `$or` array) are quite implicit; extracting small helpers (e.g. `hasUnrestrictedAccess`, `hasNoAccess`) would make the control flow and intent clearer.

## Individual Comments

### Comment 1
<location path="src/casl/casl-ability.factory.ts" line_range="1936-1939" />
<code_context>
+    ];
+
+    // Remove impossible queries
+    const meaningfulQueries = queries.filter(
+      (q) =>
+        JSON.stringify(q) !==
+        JSON.stringify({
+          $expr: { $eq: [0, 1] },
+        }),
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid using JSON.stringify-based equality to detect the "no access" query shape.

Using `JSON.stringify` for query equality is brittle because it depends on property order and the exact current shape of the "no access" query from `accessibleBy`. Instead, either:
- Detect an explicit sentinel value (if `accessibleBy` can provide one),
- Check the key structure directly (e.g. `q.$expr?.$eq?.[0] === 0 && q.$expr?.$eq?.[1] === 1`), or
- Wrap `accessibleBy` to return a discriminated type for the impossible case.

This avoids subtle breakages if the upstream query shape changes.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Junjiequan]

I'm approving it as it's a bug fix and fixes the root cause that PR #2736 did not address, please merge after the failign tests are resolved.

A few things maybe worth noting for future considerations:

• meaningfulQueries could be renamed to something more descriptive based on the context, such as validQueries
• The mongoQuery building logic isImpossibleQuery, isEmptyObject, meaningfulQueries etc. might be worth moving to utility layer, so we can scope down casl-ability.ts to rule definitions only.
• { $expr: { $eq: [0, 1] } } could benefit from a short comment. e.g, // it's generated by accessibleBy() when no rules match, forcing the query to return no results.

[nitrosx]

@Junjiequan I addressed your concerns, except moving the functions to utils.
I will do that in a future PR