# accessScope() function · @imqueue/pg-prisma

Source: https://imqueue.org/api/pg-prisma/latest/pg-prisma.accessscope/
Published: 2026-08-01
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/pg-prisma 1.0.1 — generated reference, not hand-written

Build the query extension that restricts queries to the records the active access levels allow.

**Signature:**

```typescript
export declare function accessScope(input: AccessScopeOptions): (client: any) => import("@prisma/client/extension").PrismaClientExtends<import("@prisma/client/runtime/client").InternalArgs<{}, {}, {}, {}>>;
```

## Parameters


| Parameter | Type | Description |
| --- | --- | --- |
| input | [AccessScopeOptions](https://imqueue.org/api/pg-prisma/latest/pg-prisma.accessscopeoptions/) | The per-model scope config and one resolver per level. |


**Returns:**

(client: any) => import("@prisma/client/extension").PrismaClientExtends<import("@prisma/client/runtime/client").InternalArgs<{}, {}, {}, {}>>

A Prisma extension to pass to `client.$extends()`.

## Remarks

For each scoped model, every level whose resolver returns a value contributes an OR across that level's columns; the level filters are AND-ed together and AND-ed onto the caller's `where`. A caller therefore cannot widen out of scope, and no scope column can be spoofed by supplying it in the query. A `null` from a resolver denies by matching nothing (`IN ()`), and an array becomes an `IN` — including an empty array, which also denies.

Coverage is ten operations: the reads (`findMany`, `findFirst`, `findUnique`, their `OrThrow` variants and `count`) plus `update`, `updateMany`, `delete` and `deleteMany`. On the writes the effect is silent rather than an error — an out-of-scope `updateMany` simply affects no rows, and an out-of-scope `update` throws the ordinary not-found. `create` is deliberately untouched: there is no existing row to filter, and ownership is stamped by [authorship()](https://imqueue.org/api/pg-prisma/latest/pg-prisma.authorship/).

Relations are never touched. A nested `where`, `include` or `select` is fetched as-is, so reaching a scoped model through a relation bypasses the scope — filter explicitly at those call sites when it matters.

## Example


```typescript
const client = new PrismaClient().$extends(accessScope({
    models: ACCESS_SCOPE_MODELS,
    resolvers: {
        // undefined for an admin: the level does not constrain them at all
        tenant: () => context.get()?.tenantId,
    },
}));
```

