Close is_public-extract parity gap in source visibility builders

Reviewing the visible_extracts_for docstring surfaced a latent
filter/check parity violation (same class as the group-grant drift this
PR fixes): user_can's privacy recursion delegates to
Extract.objects.user_can, which grants READ on is_public extracts for
authenticated users, while the list-side privacy gates omitted the flag
for extracts (analyses always included it). An extract-rooted row on a
public extract therefore passed user_can(READ) but never surfaced in
visible_to_user or service listings — a public-extract fixture would
have failed the parity invariant.

visible_extracts_for now includes is_public on the authenticated branch
(anonymous still gets none — ExtractManager denies outright), mirroring
visible_analyses_for. No practical exposure today: no user-facing flow
sets Extract.is_public. Pinned by
test_public_extract_source_passes_both_surfaces; changelog updated.

Author: claude

changelog.d/perm-audit-2026-06.security.md

@@ -1,4 +1,4 @@
 - **Relationship privacy recursion implemented (closes the Phase-C deferral from issue #1655).** `RelationshipManager.user_can` and `RelationshipManager.visible_to_user` (`opencontractserver/shared/Managers.py`) now enforce `created_by_analysis` / `created_by_extract` source permissions exactly like annotations: non-creators need the requested permission on the source Analysis/Extract in addition to the doc+corpus MIN. Previously a user with doc+corpus grants could see and write analysis-/extract-private relationships through the manager surfaces. The recursion logic is shared with `AnnotationManager` via the new module-level `_source_privacy_recursion_passes`. Parity pinned by new fixtures/tests in `opencontractserver/tests/permissioning/test_authorization_invariants.py` (`RelationshipAuthorizationInvariantsTestCase` — the old `test_no_privacy_widening_via_created_by_analysis` sentinel that documented the deferral is replaced by real privacy invariants) and `opencontractserver/tests/permissioning/test_relationship_privacy_scoping.py`.
 - **Extracts locked down to never be anonymous-visible.** `ExtractService.get_visible_extracts` / `check_extract_permission` (`opencontractserver/extracts/services/extract_service.py`) previously exposed `is_public` extracts in public corpora to anonymous callers (drift copied from the analysis service, reachable through the un-gated `extracts` GraphQL resolver), contradicting the documented "Extract — never" anonymous contract. A new `ExtractManager` (`opencontractserver/extracts/models.py`) denies anonymous users on both `visible_to_user` and `user_can` so the rule holds at the manager layer too (e.g. agent tools listing extracts). User-visible consequence: anonymous viewers of a public corpus now see `totalExtracts: 0` in `corpusStats` (the resolver's counts are per-viewer by contract). Two legacy tests that pinned the old semantic were updated to the agreed behavior: `test_query_optimizer_methods.py::test_get_visible_extracts_anonymous_only_public` (now `..._anonymous_sees_nothing`) and `test_stats.py::test_public_corpus_stats_query` (anonymous branch). New coverage: `opencontractserver/tests/permissioning/test_extract_anonymous_lockdown.py`.
-- **Group-granted analysis/extract permissions now unlock private rows in list queries.** The `created_by_*` privacy gates in `AnnotationQuerySet.visible_to_user` (`opencontractserver/shared/QuerySets.py`), `AnnotationService.get_document_annotations` / `get_corpus_annotations`, and `RelationshipService.get_document_relationships` consulted only the USER object-permission tables, so a viewer whose source grant arrived via a Django group passed `user_can` (which resolves group grants by default) but never saw the rows in lists — a filter/check parity drift. All gates now route through the new shared builders in `opencontractserver/utils/source_visibility.py`, which join the group object-permission tables. Tests: `test_source_visibility_group_grants.py` + new invariant fixtures.
+- **Group-granted analysis/extract permissions now unlock private rows in list queries.** The `created_by_*` privacy gates in `AnnotationQuerySet.visible_to_user` (`opencontractserver/shared/QuerySets.py`), `AnnotationService.get_document_annotations` / `get_corpus_annotations`, and `RelationshipService.get_document_relationships` consulted only the USER object-permission tables, so a viewer whose source grant arrived via a Django group passed `user_can` (which resolves group grants by default) but never saw the rows in lists — a filter/check parity drift. All gates now route through the new shared builders in `opencontractserver/utils/source_visibility.py`, which join the group object-permission tables. The same parity class also covered `Extract.is_public`: the inline gates omitted the flag for extracts (while honouring it for analyses) even though `user_can`'s recursion grants READ on public sources — `visible_extracts_for` now includes `is_public` on the authenticated branch (no practical exposure today: no user-facing flow sets the flag). Tests: `test_source_visibility_group_grants.py` + new invariant fixtures incl. `test_public_extract_source_passes_both_surfaces`.
 - **Anonymous privacy leak in corpus-wide annotation listing fixed.** `AnnotationService.get_corpus_annotations` applied the `created_by_*` privacy exclusion only to authenticated users — anonymous viewers of a public corpus could see analysis-/extract-private annotations on public documents. The exclusion now applies unconditionally (anonymous resolves to public-analyses-only / no extracts via `source_visibility`).

opencontractserver/tests/permissioning/test_authorization_invariants.py

@@ -1623,6 +1623,50 @@ def test_group_granted_source_read_passes_both_surfaces(self):
             "visible_to_user must honour the group-level READ grant on the source",
         )
 
+    def test_public_extract_source_passes_both_surfaces(self):
+        """A PUBLIC extract unlocks its extract-rooted rows for authenticated
+        viewers on BOTH surfaces (2026-06 audit follow-up): ``user_can``'s
+        privacy recursion grants READ on ``is_public`` sources via
+        ``Extract.objects.user_can``, and the list gates previously omitted
+        the flag for extracts (while honouring it for analyses) — a latent
+        filter/check parity violation. ``visible_extracts_for`` now includes
+        ``is_public`` on the authenticated branch; this pins the two
+        surfaces agreeing. (Anonymous users still see nothing —
+        ``ExtractManager`` denies them outright.)
+        """
+        from opencontractserver.annotations.models import Annotation
+        from opencontractserver.extracts.models import Extract
+
+        public_extract = Extract.objects.create(
+            name="Public Invariant Source Extract",
+            corpus=self.corpus,
+            fieldset=self.fieldset,
+            creator=self.creator,
+            is_public=True,
+        )
+        rooted = Annotation.objects.create(
+            raw_text="via_public_extract",
+            json={"x": 6},
+            page=1,
+            annotation_label=self.token_label,
+            creator=self.creator,
+            document=self.document,
+            corpus=self.corpus,
+            created_by_extract=public_extract,
+        )
+        # shared_reader has doc+corpus READ but no grant on the extract.
+        self.assertTrue(
+            rooted.user_can(self.shared_reader, PermissionTypes.READ),
+            "user_can must grant READ via the PUBLIC source extract",
+        )
+        self.assertTrue(
+            Annotation.objects.visible_to_user(self.shared_reader)
+            .filter(pk=rooted.pk)
+            .exists(),
+            "visible_to_user must include rows rooted in a PUBLIC extract "
+            "(parity with user_can's recursion)",
+        )
+
     def test_is_public_does_not_grant_writes(self):
         """SECURITY: ``is_public=True`` grants a non-creator READ but never
         UPDATE/DELETE — the write asymmetry must hold for Annotation."""

opencontractserver/utils/source_visibility.py

@@ -73,9 +73,21 @@ def visible_extracts_for(user: Any) -> QuerySet:
 
     Returns a lazy queryset (safe to embed as a subquery via
     ``__in=...``): nothing for anonymous users (extracts are never
-    anonymous-visible); own | user-granted | group-granted extracts for
-    authenticated users. ``is_public`` is intentionally absent — extract
-    privacy has never keyed off the flag and no user-facing flow sets it.
+    anonymous-visible — ``ExtractManager`` denies them on both surfaces, so
+    the flag is irrelevant on that branch); public | own | user-granted |
+    group-granted extracts for authenticated users.
+
+    ``is_public`` note: the original inline implementations omitted the
+    flag for extracts (while including it for analyses). That was a latent
+    filter/check parity violation, not a design choice — ``user_can``'s
+    privacy recursion delegates to ``Extract.objects.user_can``, which
+    grants READ on ``is_public`` rows for authenticated users, so an
+    extract-rooted row on a public extract passed ``user_can(READ)`` while
+    never appearing in lists. Including the flag here (authenticated branch
+    only) restores parity and mirrors ``visible_analyses_for``. No
+    user-facing flow currently sets ``Extract.is_public``, so this has no
+    practical exposure today; pinned by
+    ``test_public_extract_source_passes_both_surfaces``.
     """
     from django.db.models import Q
 
@@ -88,7 +100,7 @@ def visible_extracts_for(user: Any) -> QuerySet:
     if user is None or getattr(user, "is_anonymous", True):
         return Extract.objects.none()
 
-    visible = Extract.objects.filter(Q(creator=user))
+    visible = Extract.objects.filter(Q(creator=user) | Q(is_public=True))
 
     user_grant_ids = ExtractUserObjectPermission.objects.filter(user=user).values_list(
         "content_object_id", flat=True