FOUR-32946 Improve the API /api/1.0/processes

[devmiguelangel]

Issue & Reproduction Steps

Improve the API /api/1.0/processes

Solution

• Improves the performance of GET /api/1.0/processes by moving pagination into the database and eliminating unnecessary per-process work.
• Previously, the endpoint loaded the entire matching process collection, including large BPMN/SVG fields and event data, performed enrichment across every matching process, and only then converted the collection into a paginator. As the number of processes increased, response time and query work increased even when the requested page size remained unchanged.
• The endpoint now applies filtering, sorting, and pagination in SQL before serializing or enriching the requested page.

Related Tickets & Packages

FOUR-32946

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[cursor]

PR Summary

Medium Risk
Listing response shape and query behavior changed (no startEvents/heavy fields on index; bookmark/launchpad defaults). Any client or package that relied on the old full-collection semantics or with=events on the process list should be verified.

Overview
Refactors GET /api/1.0/processes so filtering, sorting, and pagination run in SQL instead of loading every matching process into memory and paginating in PHP. The listing query now omits bpmn and svg, qualifies sort columns on processes.*, and only enriches the current page (bookmark/launchpad lookups run only when bookmark / launchpad are true; otherwise bookmark_id is 0 and launchpad is null).

Notification data is batched: notification_settings are eager-loaded once per page, accessors on Process read the loaded relation (avoiding per-flag queries), and the raw relation is hidden from JSON while notifications / task_notifications still serialize. projects is dropped from listing appends, and the controller stops building startEvents / events-driven manual-start filtering on this endpoint (the process designer UI no longer requests with=events).

A small fix in ProcessMakerModel::scopeExclude uses getTable() for qualified column names. Feature tests lock in designer table fields, bounded query counts, PMQL pagination, sort-by joined user/category, and optional bookmark/launchpad behavior.

^{Reviewed by Cursor Bugbot for commit fdd28de. Bugbot is set up for automated code reviews on this repo. Configure here.}

[decisions-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube