[TTAHUB-5378] Fix CLASS same grant matching and align widget/page counts

[kryswisnaskas]

Description of change

This updates the QA CLASS dashboard backend query so the widget and details dataset use the same grant matching rules.

It requires the CLASS goal and CLASS scores to qualify on the same grant, fixes CLASS summary matching when one review spans multiple grants, and builds the widget counts from the same qualifying grant population used by the details dataset.

This change does not implement the separate timeline based review association rules from TTAHUB-5463.

How to test

1. In the QA dashboard, open Recipients with CLASS scores and goals.
2. Verify a recipient only qualifies when at least one grant has both a CLASS goal and CLASS scores on the same grant.
3. Verify a review that spans multiple grants does not let one grant inherit another grant's CLASS scores.
4. Verify a grant with a CLASS goal and CLASS score but no AR still qualifies, and the details dataset returns a blank Last AR start date.
5. Verify the query uses the most recent CLASS score for the same grant.

Jira Issue(s)

• https://jira.acf.gov/browse/TTAHUB-5378

Checklists

Every PR

• Linked Jira issue
• JIRA issue status updated
• Code is meaningfully tested
• [n/a] Meets accessibility standards (WCAG 2.1 Levels A, AA)
• [n/a] API Documentation updated
• [n/a] Boundary diagram updated
• [n/a] Logical Data Model updated
• [n/a] Architectural Decision Records written for major infrastructure decisions
• [n/a] UI review complete
• QA review complete

Before merge to main

• OHS demo complete
• Ready to create production PR

Production Deploy

• PR created as Draft
• Staging smoke test completed
• PR transitioned to Open (this ready_for_review transition triggers the Slack/Jira automation)
• Reviewer added after the PR is Open (elainaparrish is the authorized approver under normal circumstances)
  • Sequence: Draft PR → Smoke test → Open PR (automation runs) → Add reviewer
  • Confirm that the Slack notification was sent after the PR was opened
  • Confirm that linked Jira ticket(s) transitioned as expected; if not, review the GitHub Actions workflow logs

After merge/deploy

• Update JIRA ticket status

[Copilot]

Pull request overview

This PR updates the QA CLASS dashboard SQL to ensure the widget and details page are driven by the same “qualifying” population: CLASS goals must be linked to an approved activity report, and CLASS scores must be matched on the same grant with a report delivery date on/before the qualifying activity start date.

Changes:

• Refactors class.sql to compute qualifying CLASS rows at the grant level (same-grant goal+score matching) and reuse that population for both widget and page datasets.
• Adjusts the details-page selection to choose the most recent eligible CLASS score on/before the last approved activity start date.
• Expands backend SQL tests to cover cross-grant mismatches, multi-grant shared reviews, and the “most recent eligible score” selection logic.

Impact assessment:

• Benefits: Medium (fixes correctness and aligns widget/page counts off the same matching rules).
• Risks: Medium (non-trivial SQL refactor affecting dashboard semantics and performance; test cleanup issue noted in comments).

Reviewed changes

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

File	Description
src/queries/api/dashboards/qa/class.sql	Reworks CLASS widget/page dataset logic to match goals and scores on the same grant and select the most recent eligible score relative to approved activity start dates.
src/queries/api/dashboards/qa/class.test.js	Updates/extends query tests and adds helpers to create approved activity reports that qualify CLASS goals for matching.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[AdamAdHocTeam]

Three things to double check from AI:

1. (Medium) New "must have approved AR activity" requirement is a meaningful semantic change
   class_goals_with_activity (class.sql:838-862) inner-joins ActivityReportGoals and ActivityReports (LEFT JOIN, but the HAVING MAX(a."startDate") IS NOT NULL makes it effectively required) and filters to calculatedStatus = 'approved'. Goals with no approved AR are now excluded from both the widget numerator and the page list.

Previously the page CTE included rows even when there were no approved ARs (it left-joined and used (ARRAY_AGG(a."startDate" ...))[1] which could be NULL). This means recipients with a CLASS goal and CLASS scores but no approved AR activity yet will drop off the dashboard.

Confirm with the product owner that this is the intended behavior; if so, the JIRA acceptance criteria and any user-facing release notes should say so explicitly.

2. (Medium) Reviews delivered after the last approved AR are now ignored
   The temporal predicate cgwa."lastARStartDate"::date >= gcr."reportDeliveryDate"::date (class.sql:884) means a CLASS review delivered after all approved AR activity on the goal will not match. The "later review" test case (class.test.js:740 area) exercises this and expects the older review to win.

This is a deliberate change but may surprise users who expect to see the most recent CLASS scores regardless of AR timing. Worth double-checking the requirements; if the intent is "scores known at the time of the most recent TTA work", the rule is correct.

3. (Low) vf.name = 'Goals' filter moved from JOIN to FILTER clause
   In class_goal_collaborators (class.sql:925-956), the previous query had LEFT JOIN "ValidFor" vf ON ct."validForId" = vf.id AND vf.name = 'Goals', which kept rows for non-Goals collaborator types (with vf.id NULL) but they would still be excluded from the alphabetical-first creator pick because ct.name filters did not exclude them by validFor. The new code requires vf.name = 'Goals' inside each FILTER (...) clause. This is more strictly correct, but is a subtle behavioral tightening worth noting.

[kryswisnaskas]

@AdamAdHocTeam Thanks, I double checked these.
1 and 2 were addressed in the current version of the query
On 3, I see the point, but I prefer not to expand TTAHUB-5378 for that. It is a small collaborator selection detail and not part of the bug this PR is fixing.