Add query parameters for related entities on GET permissions

[hminsky2002]

This adds optional filter query parameters, mirroring the existing GET /proposals filtering pattern on Context entity, changemaker, funder, dataProvider, proposal and Grantee, granteeType and verb. This means adding a dataprovider parameters extractor, a granteeType, and a verb extractor method.

Issue #2447 Add filtering to permission grant queries

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.85%. Comparing base (e80cb9a) to head (45bfbf6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2464      +/-   ##
==========================================
+ Coverage   93.77%   93.85%   +0.08%     
==========================================
  Files         312      315       +3     
  Lines        3968     4020      +52     
  Branches      545      552       +7     
==========================================
+ Hits         3721     3773      +52     
  Misses        246      246              
  Partials        1        1              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[bickelj]

@hminsky2002 I'm not sure what happened with the preview env but I expect if you push again it should succeed.

[github-actions]

🔎 A preview deployment of this pull request is available at https://utilities.philanthropydatacommons.org/pdc-service-preview-2464-2i2wg/ (and upstream https://pdc-service-preview-2464-2i2wg.ondigitalocean.app) assuming this PR is still open. 🔍

[Copilot]

Pull request overview

Copilot reviewed 25 out of 25 changed files in this pull request and generated 1 comment.

[bickelj]

I tried this change in the preview environment and the filters seemed to work just fine and as designed. This is a wonderful change but given the recent performance concern and two models flagging a potential performance issue, I would like to double-check that performance is as expected using a demo-like database. I didn't notice any big performance hit when trying the preview environment, but I don't recall a performance issue being found in that one before.

@hminsky2002 I'll send you a database backup in case you don't already have it.

[bickelj]

The way this looks in OpenAPI spec:

The message is clear but the escaping is a bit distracting.

[bickelj]

Both Qwen3.6-35B-A3B and GLM-5.2 flagged a potential performance issue in the above block.

Qwen:

The new selectWithPagination.sql uses CASE WHEN :param::type IS NULL THEN TRUE ELSE column = :param END for each filter. This pattern prevents PostgreSQL from using indexes on the filtered columns because the expression is non-sargable. Consider dynamic SQL (building the query string based on which parameters are provided) or a WHERE (param IS NULL OR column = param) pattern instead. This is a performance concern for large tables.

GLM:

Correct: = any(permission_grants.verbs) is the right way to match "grants that include this verb", and the test filters by verb, matching grants that include the verb confirms a [view, edit] grant matches verb=edit while a [manage]-only grant does not.

Optional scale note: array-containment can't use a btree index, so if this filter becomes hot, a GIN index on permission_grants.verbs would help. Tiny consistency nit: granteeType casts only in the WHEN branch (relies on column type inference in ELSE), whereas verb casts in both branches — harmless, just FYI.

I wouldn't have mentioned it except two different models mentioned something here. I'm not sure how germane it is.

Do you have a copy of the demo database on which to try this change?

[bickelj]

This might be more related to the bundle function generator than your call here, but is there any way to avoid explicit undefineds? Does limit and offset have to be the last args or could the new optional args be the last ones and therefore not need the undefined?