@opensaas/stack-core 0.37.0 → 0.38.0

package/.turbo/turbo-build.log

@@ -1,4 +1,4 @@
 
-> @opensaas/stack-core@0.37.0 build /home/runner/work/stack/stack/packages/core
+> @opensaas/stack-core@0.38.0 build /home/runner/work/stack/stack/packages/core
 > tsc
 

package/CHANGELOG.md

@@ -1,5 +1,73 @@
 # @opensaas/stack-core
 
+## 0.38.0
+
+### Minor Changes
+
+- [#873](https://github.com/OpenSaasAU/stack/pull/873) [`b21d8b2`](https://github.com/OpenSaasAU/stack/commit/b21d8b2af43f7a2a7ea10a89cfb39140a856bd68) Thanks [@borisno2](https://github.com/borisno2)! - Naming a relation in an `include` now fetches only that relation's own columns and stops, at every level — not just the root. This completes ADR-0024 (a bare read fetches scalars, never relations): reaching a relation's own relations means naming them too, e.g. `include: { author: { include: { organization: true } } }` rather than relying on `include: { author: true }` to pull `organization` in automatically. A relation nobody named (caller `include`, fragment `query`, or a field's `needs`) never has its list's operation-level `query` access evaluated at all.
+
+  **This is a silent break — detect it before you upgrade.** An `include` that named a relation bare and read past it (`item.<named>[0].<unnamed>`) now gets `undefined` for the unnamed part, with no error. Grep your codebase for `include: {` calls whose consumers read a second hop off a bare-named relation, and add the deeper relation explicitly:
+
+  ```typescript
+  // Before: relied on `author` auto-expanding its own `organization` relation
+  const post = await context.db.post.findUnique({
+    where: { id },
+    include: { author: true },
+  })
+  post.author.organization // silently undefined now
+
+  // After: name the relation you actually need
+  const post = await context.db.post.findUnique({
+    where: { id },
+    include: { author: { include: { organization: true } } },
+  })
+  post.author.organization // present
+  ```
+
+  `AccessScopeDepthExceededError` (thrown when an `include` names a relation past `READ_INCLUDE_MAX_DEPTH`) keeps its type, fields, and throw sites — only its message wording changed, from describing an inability to scope to describing a cost refusal, since the depth cap is now a cost limit rather than a security boundary (nothing walks the relationship graph unprompted anymore).
+
+- [#890](https://github.com/OpenSaasAU/stack/pull/890) [`17eb72f`](https://github.com/OpenSaasAU/stack/commit/17eb72f0a9a4b7508e3f318da66bb8d4c6cbd705) Thanks [@list({](https://github.com/list({)! - A computed field — any field carrying a `resolveOutput` hook, virtual or not — is now computed if and only if a read is actually going to return it. A fragment `query` that selects three fields no longer runs every `resolveOutput` on the list and discards the rest: an unselected field's field-level read access is never evaluated and its hook never runs. Its declared relations (`needs`, ADR-0025) are fetched under exactly the same condition, folded recursively at every nesting level — a nested fragment selecting a subset computes only that subset, while a nested `include` still computes every computed field at that level, matching bare and `include`-based reads, which are unaffected: they still compute every computed field on the list, exactly as before. See ADR-0027.
+
+  **This is a silent break — detect it before you upgrade, the same way ADR-0024's and ADR-0026's were.** Two independent behaviors changed with no thrown error:
+
+  1. **A hook's `item` never carries another computed field's resolved output, on any read path.** Previously a virtual field received the already-assembled, already-resolved object, so a virtual field could read an _earlier-declared_ virtual (or any field carrying its own `resolveOutput`, e.g. a `password()`'s wrapper or a formatted display field) and see its resolved value — working only by declaration order, with reordering two fields silently changing the result. Now every computed field's hook sees only the row's stored columns and its own declared dependencies; reaching for a sibling that is itself computed finds nothing there (or its raw stored form, never the wrapped/resolved value), the same as reaching for a field that was never declared. **Grep your config for a `resolveOutput` whose `item` reads a field that is itself computed** — virtual fields reading other virtual fields, or a hook reading a stored field that carries its own `resolveOutput` (a password wrapper, a formatted date) — and recompute from the shared stored columns instead of relying on another field's hook having already run.
+  2. **A field's hook no longer runs just because it's on the list — only because a read selects it.** If you relied on a `resolveOutput` hook running for a side effect (logging, cache warming) on every read regardless of a fragment's own field selection, that side effect now only fires when the fragment actually names the field. **Grep for a fragment `query` that intentionally omits a field whose hook you were relying on for a side effect**, and select that field explicitly (or move the side effect to a hook that isn't projection-gated, e.g. `afterOperation`).
+
+  A hookless virtual field (one with `access.read` but no `resolveOutput`) no longer has its read access evaluated at all on any read — such a field can never produce output, so under this rule it does no work at all.
+
+  ```typescript
+  // Before: `displayName` (declared after `fullNameCached`) could read the
+  // latter's resolved value purely because of declaration order.
+
+    fields: {
+      firstName: text(),
+      lastName: text(),
+      fullNameCached: virtual({
+        type: 'string',
+        hooks: { resolveOutput: ({ item }) => `${item.firstName} ${item.lastName}` },
+      }),
+      displayName: virtual({
+        type: 'string',
+        // item.fullNameCached is now always undefined here — recompute from
+        // the shared stored columns instead.
+        hooks: { resolveOutput: ({ item }) => `${item.fullNameCached} (${item.firstName[0]}.)` },
+      }),
+    },
+  })
+
+  // After: compute from the stored columns both fields actually share.
+  displayName: virtual({
+    type: 'string',
+    hooks: {
+      resolveOutput: ({ item }) => `${item.firstName} ${item.lastName} (${item.firstName[0]}.)`,
+    },
+  }),
+  ```
+
+### Patch Changes
+
+- [#873](https://github.com/OpenSaasAU/stack/pull/873) [`b21d8b2`](https://github.com/OpenSaasAU/stack/commit/b21d8b2af43f7a2a7ea10a89cfb39140a856bd68) Thanks [@borisno2](https://github.com/borisno2)! - Fix `needs` declarations being dropped beneath a caller-named relation that revisits a list (e.g. `include: { author: { include: { posts: true } } }`, or a self-referential `parent`), which left the revisited list's computed fields resolving over `undefined`.
+
 ## 0.37.0
 
 ### Minor Changes

package/CLAUDE.md

@@ -249,7 +249,25 @@ Reads run no `afterOperation` (list or field):
 
 ### A Bare Read Fetches Scalars, Not Relations (ADR-0024)
 
-A read with no `include` and no fragment `query` returns the row's own columns plus its virtual fields — **never relations** — matching Prisma's own default. `findUnique`, `findMany`, and a singleton's `get()` all follow this rule uniformly, under sudo and under a session alike. Relations are fetched only when a caller names them via `include` or a fragment `query`, at which point the existing merge-with-access-control path (`mergeIncludeWithAccessControl`) applies exactly as before (#566/#830 unaffected). Foreign-key columns (e.g. `authorId`) are unaffected and always returned, so a relation stays reachable by id without an `include`. A `resolveOutput` hook that issues its own bare `context.db` read is subject to the same rule — reading `item.<relation>` inside such a hook silently returns `undefined` unless the hook's own read names that relation. See `docs/adr/0024-a-read-with-no-include-fetches-scalars-not-relations.md`.
+A read with no `include` and no fragment `query` returns the row's own columns plus its virtual fields — **never relations** — matching Prisma's own default. `findUnique`, `findMany`, and a singleton's `get()` all follow this rule uniformly, under sudo and under a session alike. Relations are fetched only when a caller names them via `include` or a fragment `query`, at which point the caller-directed access-scoping walk (`buildAccessScopedInclude`, ADR-0026) applies (#566/#830 unaffected). Foreign-key columns (e.g. `authorId`) are unaffected and always returned, so a relation stays reachable by id without an `include`. A `resolveOutput` hook that issues its own bare `context.db` read is subject to the same rule — reading `item.<relation>` inside such a hook silently returns `undefined` unless the hook's own read names that relation. See `docs/adr/0024-a-read-with-no-include-fetches-scalars-not-relations.md`.
+
+### Naming a Relation Fetches Its Columns, Not Its Subtree (ADR-0026)
+
+The bare-read rule above applies at **every level**, not only the root: naming a relation in an `include` fetches that relation's own columns and stops — its own further relations are returned only if the request nests an `include` for them too. `include: { author: true }` returns `author`'s scalar columns; reaching `author.organization` means writing `include: { author: { include: { organization: true } } }`. This is the "One hop" rule (see the glossary entry in `CONTEXT.md`).
+
+The read pipeline is **caller-directed**: `buildAccessScopedInclude` walks only the branches a request (a caller `include`, a fragment `query`'s projection, or a field's folded `needs`) itself names, and never evaluates a related list's operation-level `query` access for a relation nobody asked for. There is no separate "build the full access-scoped tree for the whole list, then reconcile against what was requested" pass — the old `buildIncludeWithAccessControl` + `mergeIncludeWithAccessControl` two-step this replaced. `READ_INCLUDE_MAX_DEPTH` is a cost limit on how deep a request may reach, not a security boundary: nothing walks the relationship graph unprompted anymore, so there is no unscoped subtree left to fail open on past the cap — a request naming a relation at or beyond the cap still throws `AccessScopeDepthExceededError` (ADR-0022), now worded as a cost refusal rather than a scoping failure.
+
+**Migration note (silent break):** an `include` that named a relation bare and read past it one hop (`item.<named>[0].<unnamed>`) now gets `undefined` for the unnamed part — no error. Grep for caller includes whose consumers read past the relation actually named, and add the deeper relation explicitly to the `include`.
+
+A computed field's declared dependency (`needs`, ADR-0025, below) folds in at **every** relation it's reached through, including one added purely to satisfy another field's own `needs` — the fold recurses through `foldDeclaredDependencies` rather than riding a caller-named relation's auto-expanded subtree, since nothing auto-expands anymore. See `docs/adr/0026-naming-a-relation-fetches-its-columns-not-its-subtree.md`.
+
+### A Computed Field Runs Only When It Is Going To Be Returned (ADR-0027)
+
+A computed field — any field carrying a `resolveOutput` hook, virtual or not — is computed **if and only if the read is actually going to return it**, and its declared relations (`needs`) are fetched under exactly the same condition. A fragment `query` selecting three fields runs only those three fields' hooks (and folds only their `needs`); a field it doesn't select does no work at all — neither its field-level `read` access nor its hook runs. This is **projection-aware, never access-aware**: a fragment's own field selection is the only thing that restricts a level this way. A bare read or an `include`-based read is unaffected — every computed field on the list still computes, exactly as before, since neither ever had a narrower field selection to restrict by. The rule applies at every nesting level: a nested fragment selecting a subset computes only that subset there; a nested `include` still computes every computed field at that level.
+
+**A computed field's hook never sees another computed field's resolved output**, on any read path — only the row's stored columns and its own declared dependencies. A sibling field that was skipped (unselected by a fragment) or denied by field-level access is absent from what the hook sees, never present holding its raw pre-hook value — reaching for it finds nothing there, the same as reaching for a relation never declared via `needs`. Before this, a virtual field received the already-assembled, already-resolved object, so a virtual field could accidentally read an earlier-declared virtual's resolved value purely by declaration order; reordering two such fields silently changed the result. That accidental coupling is gone: recompute from the stored columns both fields share instead.
+
+A hookless virtual field (one with `access.read` but no `resolveOutput`) has its read access evaluated on no read at all — such a field can never produce output, so there's nothing to preserve access side effects for. See `docs/adr/0027-a-computed-field-runs-only-when-it-is-going-to-be-returned.md` and the "Computed field" glossary entry in `CONTEXT.md`.
 
 ### Context Type Safety
 
@@ -402,13 +420,13 @@ User: list({
 
 // Usage
 const user = await context.db.user.findUnique({ where: { id } })
-console.log(user.fullName) // "John Doe" — computed via resolveOutput on every read
+console.log(user.fullName) // "John Doe" — computed via resolveOutput whenever the read returns it
 ```
 
 **Key characteristics:**
 
 - Not stored in database (no Prisma column created)
-- Computed via `resolveOutput` on every read (`select` is not honoured — narrow with `include`/fragment `query`)
+- Computed via `resolveOutput` on every bare/`include`-based read; on a fragment `query` read, only when the fragment selects it (ADR-0027) — `select` is still not honoured, narrow with `include`/fragment `query`
 - Must provide `type` (TypeScript type string) and `resolveOutput` hook
 - Can optionally provide `resolveInput` for write side effects
 - Useful for derived values, computed properties, and external API sync

package/dist/access/access-filter.d.ts

@@ -1,125 +1,38 @@
-import type { Session, AccessContext, PrismaFilter } from './types.js';
+import type { Session, AccessContext } from './types.js';
 import type { OpenSaasConfig, FieldConfig } from '../config/types.js';
 /**
- * Access Filter — phase 1 of the two-phase read (pre-query).
- *
- * This module scopes which rows and relationships the database is allowed to
- * return, before the query runs. It evaluates *operation-level* `query` access
- * on related lists and turns the results into a Prisma `include`/`where` clause,
- * so denied rows and relations never leave the database.
- *
- * Phase 2 (post-query field stripping + `resolveOutput` + virtual computation)
- * lives in `field-visibility.ts`. The two phases cannot be merged: virtual
- * fields are computed in JavaScript and post-query field access can depend on
- * the fetched row, neither of which is expressible in SQL. See
- * `docs/adr/0001-access-control-is-a-two-phase-read.md` and the access-control
- * glossary in `CONTEXT.md`.
- */
-/** A single relation entry in a Prisma `include` object (see below). */
-type IncludeEntry = boolean | {
-    where?: PrismaFilter;
-    include?: IncludeObject;
-    take?: number;
-};
-type IncludeObject = Record<string, IncludeEntry>;
-/**
- * The result of trying to compute an access-controlled include for a list's
- * fields. `buildIncludeWithAccessControl` used to collapse three unrelated
- * outcomes into a single overloaded `undefined`: "inside a resolveOutput
- * context", "hit the depth cap", and "no relationships to scope" all looked
- * identical to callers, which is what let a depth-capped relation pass
- * through unscoped (issue #830). This discriminated result keeps them
- * distinguishable all the way to `mergeIncludeWithAccessControl`, which is the
- * only place that knows whether a caller actually asked for the part that
- * couldn't be scoped.
- *
- * - `scoped`: relationships were found and (to the extent depth allows)
- *   access-controlled; `include` is the resulting tree.
- * - `nothing-to-scope`: the list genuinely has no relationships to scope, OR
- *   we are inside a resolveOutput/virtual-field context and deliberately did
- *   not descend into a relation's own nested relations. Passing the caller's
- *   include through unchanged here is correct, not a leak.
- * - `depth-exceeded`: we could not evaluate this level at all because it sits
- *   at or past `READ_INCLUDE_MAX_DEPTH`. This is a denial: a caller `include`
- *   that reaches here must be rejected, not passed through.
- */
-export type AccessIncludeResult = {
-    kind: 'scoped';
-    include: RichIncludeObject;
-} | {
-    kind: 'nothing-to-scope';
-} | {
-    kind: 'depth-exceeded';
-};
-/** A relation entry in the rich, provenance-carrying tree `buildIncludeWithAccessControl` builds internally. */
-type RichIncludeEntry = {
-    where?: PrismaFilter;
-    nested: AccessIncludeResult;
-};
-type RichIncludeObject = Record<string, RichIncludeEntry>;
-/**
- * Collapse an `AccessIncludeResult` to the plain Prisma `include` shape used
- * when there is no caller-supplied include to merge against (the direct
- * auto-include path). `nothing-to-scope` and `depth-exceeded` both become
- * `undefined` here — at this call site nothing was explicitly requested past
- * either boundary, so there is nothing to deny.
- */
-export declare function toPrismaInclude(result: AccessIncludeResult): IncludeObject | undefined;
-/**
- * Build the access-controlled include for a list's fields.
- *
- * This allows us to filter relationships at the database level instead of in
- * memory. Returns an {@link AccessIncludeResult} rather than a plain include
- * object so that `mergeIncludeWithAccessControl` can tell a genuine "nothing
- * to scope" apart from "the engine hit its depth cap" (see that type's doc
- * comment and ADR-0022).
+ * Build the access-scoped `include` for exactly the relations a read
+ * requested, recursing only into branches `requestedInclude` itself names.
+ *
+ * For each key in `requestedInclude`:
+ * - Not a config-declared relationship → access control does not govern it;
+ *   passed through unchanged (e.g. a fragment/caller key that isn't a
+ *   relationship at all).
+ * - A declared relationship whose related list's `query` access denies it
+ *   (`=== false`) → dropped entirely, no matter what the request asked for
+ *   nested beneath it (#566): the caller chooses *which* relations, access
+ *   control chooses *whether* and *with what filter*.
+ * - Otherwise → the access `where` is AND-combined with any caller-supplied
+ *   nested `where` (never replaced — the other half of #566), a
+ *   caller-supplied `take` rides through unchanged (#752), and — the "One
+ *   hop" rule (ADR-0026) — nested relations are scoped ONLY if
+ *   `requestedInclude` itself named a nested `include` here. A bare relation
+ *   (or one with no nested `include`) fetches its own columns and stops: no
+ *   recursive call, no access evaluation on anything beneath it.
+ *
+ * **Depth is a cost limit, not a cycle guard (ADR-0026).** A `requestedInclude`
+ * is always a finite literal — the caller's own object, or
+ * `foldDeclaredDependencies`'s already-cycle-guarded fold — so this recursion
+ * cannot loop unboundedly on its own; nothing here walks the relationship
+ * graph unprompted. `READ_INCLUDE_MAX_DEPTH` still bounds how deep a request
+ * may reach, fail-closed per ADR-0022: a request naming anything at or past
+ * the cap throws `AccessScopeDepthExceededError` rather than silently
+ * returning less than what was asked for.
  */
-export declare function buildIncludeWithAccessControl(fieldConfigs: Record<string, FieldConfig>, args: {
+export declare function buildAccessScopedInclude(requestedInclude: Record<string, unknown>, fieldConfigs: Record<string, FieldConfig>, args: {
     session: Session | null;
     context: AccessContext;
-}, config: OpenSaasConfig, depth?: number, visitedLists?: readonly string[]): Promise<AccessIncludeResult>;
-/**
- * Merge a caller-supplied `include` with the access-controlled include — phase-1
- * row/relation scoping for explicit caller selections.
- *
- * The caller's `include` decides WHICH relations to fetch; access control decides
- * WHETHER each relation may be fetched and WITH WHAT filter. Replacing the
- * access-controlled include with the caller's wholesale (the bug in #566) drops
- * every per-relation access `where` and denied-relation exclusion, silently
- * bypassing row-level access on any non-sudo read that passes `include`.
- *
- * For each relation the caller asks to include:
- * - If the relation is a config-declared relationship but is ABSENT from the
- *   access-controlled include, its `query` access returned `false` → it is DROPPED
- *   (not fetched).
- * - If it is present (allowed, possibly with a filter), the access entry is used
- *   as the base: the access `where` is AND-combined with any caller-supplied
- *   nested `where`, and nested includes are recursively merged using the related
- *   list's field configs (so deeply-nested selections are filtered at every
- *   level). A bare caller `true` becomes the access-controlled shape (filter +
- *   nested filtered include), never bare `true`.
- * - If the caller names a key that is NOT a config-declared relationship, it is
- *   passed through unchanged (access control does not govern it).
- *
- * `accessControlledInclude` is the {@link AccessIncludeResult} for THIS level:
- * - `nothing-to-scope` → nothing to merge against (the list has no
- *   relationships, or we're inside a resolveOutput context where the caller
- *   include is irrelevant to begin with). Pass the caller's include through
- *   unchanged — this is a non-denial outcome, not "every relation denied".
- * - `depth-exceeded` → the engine could not compute a scope for THIS level at
- *   all because it sits at or past `READ_INCLUDE_MAX_DEPTH`. If the caller
- *   named anything here, that is exactly the case that used to pass through
- *   unscoped (issue #830): throw `AccessScopeDepthExceededError` instead. An
- *   empty caller include at this level (nothing further requested) is not an
- *   error — there's simply nothing to do.
- * - `scoped` → the normal per-relation merge below: a declared relationship
- *   ABSENT from the access include was denied (drop it); one PRESENT is used
- *   as the base, AND-combining `where`s and recursing into nested includes.
- *
- * `listKey` and `depth` are carried only to build a useful
- * `AccessScopeDepthExceededError` message; they do not affect merge behaviour.
- */
-export declare function mergeIncludeWithAccessControl(callerInclude: Record<string, unknown>, accessControlledInclude: AccessIncludeResult, fieldConfigs: Record<string, FieldConfig>, config: OpenSaasConfig, listKey: string, depth?: number): Record<string, unknown>;
+}, config: OpenSaasConfig, listKey: string, depth?: number): Promise<Record<string, unknown>>;
 /**
  * Remove keys that correspond to `virtual` fields from a Prisma `include`
  * object, recursing into nested relationship includes using the related
@@ -137,5 +50,4 @@ export declare function mergeIncludeWithAccessControl(callerInclude: Record<stri
  * no effect on whether the value appears in the result (#628).
  */
 export declare function stripVirtualFieldsFromInclude(include: Record<string, unknown> | undefined, fieldConfigs: Record<string, FieldConfig>, config: OpenSaasConfig): Record<string, unknown> | undefined;
-export {};
 //# sourceMappingURL=access-filter.d.ts.map

package/dist/access/access-filter.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"access-filter.d.ts","sourceRoot":"","sources":["../../src/access/access-filter.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,aAAa,EAAE,YAAY,EAAE,MAAM,YAAY,CAAA;AACtE,OAAO,KAAK,EAAE,cAAc,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAA;AAKrE;;;;;;;;;;;;;;GAcG;AAEH,wEAAwE;AACxE,KAAK,YAAY,GAAG,OAAO,GAAG;IAAE,KAAK,CAAC,EAAE,YAAY,CAAC;IAAC,OAAO,CAAC,EAAE,aAAa,CAAC;IAAC,IAAI,CAAC,EAAE,MAAM,CAAA;CAAE,CAAA;AAC9F,KAAK,aAAa,GAAG,MAAM,CAAC,MAAM,EAAE,YAAY,CAAC,CAAA;AAEjD;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,MAAM,mBAAmB,GAC3B;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,OAAO,EAAE,iBAAiB,CAAA;CAAE,GAC9C;IAAE,IAAI,EAAE,kBAAkB,CAAA;CAAE,GAC5B;IAAE,IAAI,EAAE,gBAAgB,CAAA;CAAE,CAAA;AAE9B,gHAAgH;AAChH,KAAK,gBAAgB,GAAG;IAAE,KAAK,CAAC,EAAE,YAAY,CAAC;IAAC,MAAM,EAAE,mBAAmB,CAAA;CAAE,CAAA;AAC7E,KAAK,iBAAiB,GAAG,MAAM,CAAC,MAAM,EAAE,gBAAgB,CAAC,CAAA;AAqBzD;;;;;;GAMG;AACH,wBAAgB,eAAe,CAAC,MAAM,EAAE,mBAAmB,GAAG,aAAa,GAAG,SAAS,CAOtF;AAED;;;;;;;;GAQG;AACH,wBAAsB,6BAA6B,CACjD,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,EACD,MAAM,EAAE,cAAc,EACtB,KAAK,GAAE,MAAU,EAIjB,YAAY,GAAE,SAAS,MAAM,EAAO,GACnC,OAAO,CAAC,mBAAmB,CAAC,CAwE9B;AAiDD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,wBAAgB,6BAA6B,CAC3C,aAAa,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EACtC,uBAAuB,EAAE,mBAAmB,EAC5C,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,MAAM,EAAE,cAAc,EACtB,OAAO,EAAE,MAAM,EACf,KAAK,GAAE,MAAU,GAChB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CA2EzB;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,6BAA6B,CAC3C,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,EAC5C,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,MAAM,EAAE,cAAc,GACrB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CAgCrC"}
+{"version":3,"file":"access-filter.d.ts","sourceRoot":"","sources":["../../src/access/access-filter.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,aAAa,EAAgB,MAAM,YAAY,CAAA;AACtE,OAAO,KAAK,EAAE,cAAc,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAA;AA6ErE;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AACH,wBAAsB,wBAAwB,CAC5C,gBAAgB,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EACzC,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,IAAI,EAAE;IACJ,OAAO,EAAE,OAAO,GAAG,IAAI,CAAA;IACvB,OAAO,EAAE,aAAa,CAAA;CACvB,EACD,MAAM,EAAE,cAAc,EACtB,OAAO,EAAE,MAAM,EACf,KAAK,GAAE,MAAU,GAChB,OAAO,CAAC,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC,CAwDlC;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,6BAA6B,CAC3C,OAAO,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,EAC5C,YAAY,EAAE,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,EACzC,MAAM,EAAE,cAAc,GACrB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,GAAG,SAAS,CAgCrC"}