feat: return unfiltered_total in project list response

[JohnRDOrazio]

Summary

• Adds unfiltered_total field to ProjectListResponse schema, representing the total count of projects accessible to the user before any search or filter params are applied
• Restructures list_accessible in ProjectService to compute the unfiltered count from the access-control query before applying filter_type and search
• Enables the frontend to show context like "Showing 3 projects (filtered from 42)"

Closes #34

Test plan

• Verify GET /api/v1/projects returns unfiltered_total equal to total when no filters/search are applied
• Verify unfiltered_total stays constant when applying filter_type=public, filter_type=mine, filter_type=private, or search=...
• Verify anonymous users get correct unfiltered_total (count of all public projects)
• Verify unfiltered_total is always >= total

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Project list API responses now include a new unfiltered_total field alongside the existing filtered total count. This metric displays the total number of accessible projects before any search terms or type-based filters are applied, allowing users to better understand the complete scope of available projects versus filtered results.

[coderabbitai]

📝 Walkthrough

Walkthrough

The ProjectListResponse schema now includes an unfiltered_total field, and ProjectService.list_accessible computes this value as the count of all projects matching access-control criteria before applying search and filter parameters. The filtered total continues to reflect the count after filtering, while the new field shows the broader universe of accessible projects.

Changes

Cohort / File(s)	Summary
Schema Update ontokit/schemas/project.py	Added unfiltered_total: int field to ProjectListResponse to expose the count of accessible projects before filtering.
Service Logic ontokit/services/project_service.py	Centralized access-control logic into access_clause and introduced computation of unfiltered_total before filter_type and search are applied; simplified query construction and extended response payload.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• feat: add search parameter to project list endpoint #28 — Overlaps with modifications to ProjectService.list_accessible regarding search handling, access-filtering, and result count computation.
• feat: add filter=private to project list endpoint #35 — Also modifies ProjectService.list_accessible to adjust filter branches and access-control logic.

Suggested reviewers

• damienriehl

Poem

🐰 A count before the filters fall,
Now users see the sum of all,
Filtered results, yet unfiltered too—
Forty-two projects, filtered to few! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely summarizes the main change: adding an unfiltered_total field to the project list response.
Linked Issues check	✅ Passed	The PR fully implements the proposed solution from issue #34 by adding the unfiltered_total field to ProjectListResponse and computing it from the access-control query before applying filters/search.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing the unfiltered_total feature; no extraneous modifications detected.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/unfiltered-total

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

ontokit/services/project_service.py (1)

476-494: Consider moving subquery definition closer to its usage for clarity.

The subquery variable defined at line 464 is reused at lines 489 and 492. While this works correctly due to Python's function-level scoping (and both definition and usage occur only when user is not None), it creates an implicit coupling between distant code blocks.

For improved maintainability, consider defining the subquery once at the method level (guarded by user is not None) or inline where needed.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ontokit/services/project_service.py` around lines 476 - 494, The subquery
used in the access-control block (referenced as subquery in the
Project.id.in_(subquery) checks when filter_type is "private" or "mine") is
defined far above its usages; move its definition so it's declared immediately
before the "if user is None: ... else:" branch or inside the "else:" guard where
user is not None, or alternatively hoist a single guarded definition at the top
of the method under if user is not None to avoid the implicit coupling—ensure
the symbol name remains subquery and that its scope covers both
Project.id.in_(subquery) checks and any other access_clause construction that
relies on it.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@ontokit/services/project_service.py`:
- Around line 476-494: The subquery used in the access-control block (referenced
as subquery in the Project.id.in_(subquery) checks when filter_type is "private"
or "mine") is defined far above its usages; move its definition so it's declared
immediately before the "if user is None: ... else:" branch or inside the "else:"
guard where user is not None, or alternatively hoist a single guarded definition
at the top of the method under if user is not None to avoid the implicit
coupling—ensure the symbol name remains subquery and that its scope covers both
Project.id.in_(subquery) checks and any other access_clause construction that
relies on it.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2ce96c14-1ed6-45b4-872d-b1c66091dd1f

📥 Commits

Reviewing files that changed from the base of the PR and between 362e289 and bffa323.

📒 Files selected for processing (2)

• ontokit/schemas/project.py
• ontokit/services/project_service.py