---
url: "https://vueda.dev/v3/reference/glossary.md"
title: "Glossary"
---

# Glossary

## Action

A named operation that a VUEDA viewset exposes. The built-in actions are `list`, `retrieve`, `create`, `update`, `partial_update`, and `destroy`. Any other action is an [Extra Action](/v3/reference/glossary.md#extra-action). [Model Info](/v3/reference/glossary.md#model-info) and object payloads report actions by these names. Client routes use the same names, except `read`, which maps to the [Canonical Action Name](/v3/reference/glossary.md#canonical-action-name) `retrieve`.

- Names: [`action`](/v3/reference/api/py/vueda.core.decorators.md#action); [`ModelInfoAction`](/v3/reference/api/rest/schemas/ModelInfoAction.md); [`ActionInfo`](/v3/reference/api/js/stores/storeModelInfo/types/ActionInfo.md)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md)
- Upstream: [DRF: `action`](https://www.django-rest-framework.org/api-guide/viewsets/#marking-extra-actions-for-routing)

## Action Availability

Which actions the client offers a user. It draws them from [Model Actions](/v3/reference/glossary.md#model-actions), each object's [Available Actions](/v3/reference/glossary.md#available-actions), [Permitted Transitions](/v3/reference/glossary.md#permitted-transitions), and [Valid Transitions](/v3/reference/glossary.md#valid-transitions), and the model config's `routeActions` and `actions` narrow them. The client uses these lists for routes and buttons. The server checks each request again when it runs.

- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md)

## Action Namespace

The unified client action identifier space that includes CRUDL/extra action names and workflow transition codes.

## Action Redirect

The view an action form opens after its action succeeds or you cancel it. You set it per action in the model config's `actionRedirects`, with a `default` entry, and a `returnPath` query value takes precedence. The `actionRedirect` parameter of `makeCRUDRoutes` is a separate setting: where [Route Admission](/v3/reference/glossary.md#route-admission) sends a rejected route.

- Names: [`actionRedirects`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#actionRedirects); [`redirectTo`](/v3/reference/api/js/use/useModelAction/types/ModelActionContext.md#redirectTo)
- Described in: [Design Transition UX and Redirects](/v3/guides/transition-ux-and-redirects.md#redirect-precedence-and-route-targets)

## Action View Resolution

How `ViewActionRouter` picks the view component for a route that passed [Route Admission](/v3/reference/glossary.md#route-admission). It renders `ViewActionNotFound` when neither [Model Info](/v3/reference/glossary.md#model-info) nor the [Permitted Transitions](/v3/reference/glossary.md#permitted-transitions) list the action. Otherwise it tries the built-in view registry, then a project view named by convention, then a generic view for the action or transition. A transition code skips the built-in registry.

- Names: [`ViewActionRouter`](/v3/reference/api/vue/ViewActionRouter.md); [`setCrudComponents`](/v3/reference/api/js/router/routerComponent/functions/setCrudComponents.md); [`crudComponents`](/v3/reference/api/js/router/routerComponent.md#crudComponents); [`ViewAction`](/v3/reference/api/vue/ViewAction.md); [`ViewExecuteTransition`](/v3/reference/api/vue/ViewExecuteTransition.md); [`ViewActionNotFound`](/v3/reference/api/vue/ViewActionNotFound.md)
- Described in: [Routing and View Resolution Model](/v3/core-concepts/routing-and-view-resolution-model.md#view-component-resolution-order)

## Action-Scoped Expand

A per-action list of the relations a request to that action may [Expand](/v3/reference/glossary.md#expand), set on the viewset as `permit_<action>_expands`. An action without one allows every declared expand, except `list`, which allows none until you set `permit_list_expands`. On `list`, `retrieve`, `create`, `update`, and `partial_update`, the server rejects a request that expands a relation that the action does not permit.

- Names: `permit_<action>_expands`; [`FlexFieldsMixin`](/v3/reference/api/py/vueda.core.viewsets/FlexFieldsMixin.md)
- Described in: [Field and Expand Semantics](/v3/core-concepts/field-and-expand-semantics.md)
- Upstream: [drf-flex-fields2: `FlexFieldsSerializerMixin`](https://drf-flex-fields2.readthedocs.io/en/stable/api/rest_flex_fields2/serializers/FlexFieldsSerializerMixin.html#rest_flex_fields2.serializers.FlexFieldsSerializerMixin)

## Auth-Scoped Stores

The client stores whose cached data depends on the signed-in user's permissions: [Model Info](/v3/reference/glossary.md#model-info), [Model Config](/v3/reference/glossary.md#model-config), workflow, and model choices. When a different user signs in or the user signs out, the client empties all four, and composables fetch again. A failed model info fetch, workflow fetch, or config build stays cached for its key until a user change, a store reset, or a page reload clears it.

- Names: [`clearAuthScopedStores`](/v3/reference/api/js/stores/authScope/functions/clearAuthScopedStores.md); [`identityGeneration`](/v3/reference/api/js/stores/storeUser/functions/storeUser.md#identityGeneration); [`AuthScopeInvalidatedError`](/v3/reference/api/js/utils/errors/members/AuthScopeInvalidatedError.md)
- Described in: [Reactive Data Flow](/v3/core-concepts/reactive-data-flow.md#when-caches-clear)

## Available Actions

The `available_actions` field on an object payload: the actions the current user may perform on that object. Each built-in action that the viewset implements, except `create`, appears when an [Object-Scope Check](/v3/reference/glossary.md#object-scope-check) passes; extra actions appear when `get_allowed_extra_actions` includes them. The server includes the field only when the request asks for it through [Sparse Fields](/v3/reference/glossary.md#sparse-fields) (`f`).

- Names: [`available_actions`](/v3/reference/api/py/vueda.core.serializers/VuedaSerializer.md#available_actions); [`AvailableActionsField`](/v3/reference/api/py/vueda.core.serializers.fields/AvailableActionsField.md); [`get_allowed_extra_actions`](/v3/reference/api/py/vueda.core.viewsets/VuedaViewSet.md#get_allowed_extra_actions)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#object-scope-availability-metadata)

## Baseline Permission

The decision that Django's model permission check makes for a codename without an object, from the user's own and group permissions. It never depends on an object's state or row. It is the first of the [Permission Layers](/v3/reference/glossary.md#permission-layers), and later layers can change it for one object. Superusers pass before this check runs.

- Names: [`VUEDAPermissionsMixin.has_perm`](/v3/reference/api/py/vueda.user.mixins/VUEDAPermissionsMixin.md#has_perm)
- Described in: [Permission Model](/v3/core-concepts/permission-model.md#permission-authority-layers)
- Upstream: [Django: `ModelBackend.has_perm`](https://docs.djangoproject.com/en/6.1/ref/contrib/auth/#django.contrib.auth.backends.ModelBackend.has_perm)

## Bulk Action

An [Extra Action](/v3/reference/glossary.md#extra-action) declared with `bulk=True`. `VuedaRouter` also mounts it at the list URL, so one request can target several objects.

- Names: [`bulk`](/v3/reference/api/py/vueda.core.decorators.md#action-param-bulk); [`VuedaRouter`](/v3/reference/api/py/vueda.core.routers/VuedaRouter.md)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#server-action-declaration-and-route-partitioning)
- Upstream: [DRF: `action`](https://www.django-rest-framework.org/api-guide/viewsets/#marking-extra-actions-for-routing)

## Cancellable Promise

A promise with a `cancel()` method that aborts its HTTP request. `fetchHelper` and the default [CRUD Adapter](/v3/reference/glossary.md#crud-adapter) functions return one. Promises returned by store actions have no `cancel()`.

- Names: [`CancellablePromise`](/v3/reference/api/js/utils/fetchSupport/types/CancellablePromise.md); [`MaybeCancellablePromise`](/v3/reference/api/js/utils/fetchSupport/types/MaybeCancellablePromise.md); [`fetchHelper`](/v3/reference/api/js/utils/fetchSupport/functions/fetchHelper.md)
- Described in: [Cancellable Network Operations](/v3/core-concepts/cancellable-network-operations.md#cancellation-surface-promise-identity)
- Upstream: [reactive-helpers: `cancellableFetch`](https://reactive-helpers.arrai.dev/v25/reference/api/utils/cancellableFetch.html#cancellablefetch); [MDN: `AbortController`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)

## Canonical Action Name

The name that [Model Info](/v3/reference/glossary.md#model-info) uses for an action, which the client compares when it matches a route's action. The route segment `read` maps to the canonical name `retrieve`, and every other name maps to itself.

- Names: [`getActionName`](/v3/reference/api/js/utils/actionMap/functions/getActionName.md); [`viewToActionNameMap`](/v3/reference/api/js/utils/actionMap.md#viewToActionNameMap)
- Described in: [Routing and View Resolution Model](/v3/core-concepts/routing-and-view-resolution-model.md#action-name-normalization)
- Upstream: [DRF: `ModelViewSet`](https://www.django-rest-framework.org/api-guide/viewsets/#modelviewset)

## Canonical Registration

Registering a model with `register` or `register_serializer`, usually in `AppConfig.ready()`. It records the model's [Canonical Serializer](/v3/reference/glossary.md#canonical-serializer) and, with `register`, its [Canonical Viewset](/v3/reference/glossary.md#canonical-viewset). [Model Info](/v3/reference/glossary.md#model-info) describes only registered models.

- Names: [`register`](/v3/reference/api/py/vueda.info.registration.md#register); [`register_serializer`](/v3/reference/api/py/vueda.info.registration.md#register_serializer)
- Described in: [Canonical Registration and Model Discovery](/v3/core-concepts/canonical-registration-and-discovery.md#registration-states-and-transitions)
- Upstream: [Django: `AppConfig.ready`](https://docs.djangoproject.com/en/6.1/ref/applications/#django.apps.AppConfig.ready)

## Canonical Serializer

The serializer registered for a model. Its fields and `Meta.expandable_fields` define the field and expand sections of the model's [Model Info](/v3/reference/glossary.md#model-info).

- Names: [`canonical_serializer`](/v3/reference/api/py/vueda.info.registration.md#register-param-canonical_serializer)
- Described in: [Server-Client Metadata Contract](/v3/core-concepts/server-client-metadata-contract.md#metadata-sections)
- Upstream: [DRF: `ModelSerializer`](https://www.django-rest-framework.org/api-guide/serializers/#modelserializer)

## Canonical Viewset

The viewset registered with a model's [Canonical Serializer](/v3/reference/glossary.md#canonical-serializer). [Model Info](/v3/reference/glossary.md#model-info) reads the model's actions, filtering, and column totals from it. It also reads the orderable fields from the viewset's `ordering_fields`, and the default ordering from its `ordering` when it declares one.

- Names: [`canonical_viewset`](/v3/reference/api/py/vueda.info.registration.md#register-param-canonical_viewset); [`VuedaViewSet`](/v3/reference/api/py/vueda.core.viewsets/VuedaViewSet.md)
- Described in: [Canonical Registration and Model Discovery](/v3/core-concepts/canonical-registration-and-discovery.md#viewset-presence-and-metadata-completeness)
- Upstream: [DRF: `ModelViewSet`](https://www.django-rest-framework.org/api-guide/viewsets/#modelviewset)

## Choice-Backed Field

A field or filter whose [Model Info](/v3/reference/glossary.md#model-info) entry sets `choices` to a list or to `true`. A list of `{label, value}` pairs with string values is the complete set. The value `true` means the options are rows of another model or, for a filter, a column's current values, and the client loads them from the server when the field needs them.

- Names: [`FieldInfo.choices`](/v3/reference/api/js/stores/storeModelInfo/types/FieldInfo.md#choices); [`FilterInfo.choices`](/v3/reference/api/js/stores/storeModelInfo/types/FilterInfo.md#choices); [`model_info_choices`](/v3/reference/api/rest/vueda.info/vueda.info_model_info_choices_list.md); [`model_info_filter_choices`](/v3/reference/api/rest/vueda.info/vueda.info_model_info_filter_choices_list.md); [`useModelChoices`](/v3/reference/api/js/use/useModelChoices/functions/useModelChoices.md); [`storeModelChoices`](/v3/reference/api/js/stores/storeModelChoices/functions/storeModelChoices.md)
- Described in: [Choice-Backed Fields and Lookup Models](/v3/guides/choices-and-lookups.md)
- Upstream: [Django: `Field.choices`](https://docs.djangoproject.com/en/6.1/ref/models/fields/#django.db.models.Field.choices)

## Client Affordance

What the client shows or enables for a user, such as a visible action button or a route the guard admits. Affordances are client behavior; the server authorizes every request on its own.

- Described in: [Authorization vs UI Semantics](/v3/core-concepts/authorization-vs-ui-semantics.md)

## Column Adapter

The component that renders the cells of one list column, such as `ColumnText` or `ColumnModelLink`. A `field(<name>)` slot replaces it; otherwise VUEDA picks it from the `columnComponents` prop, then the model config's `columnComponents`, then the field type's mapping, and finally `ColumnText`.

- Names: [`resolveColumnComponent`](/v3/reference/api/js/utils/resolveColumnComponents/functions/resolveColumnComponent.md); [`columnComponents` prop](/v3/reference/api/vue/ViewList.md#prop-columnComponents); [`columnComponents` config](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#columnComponents); [`columnProps`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#columnProps); [`mergeColumnMappings`](/v3/reference/api/js/utils/columnMappings/functions/mergeColumnMappings.md); [`ColumnText`](/v3/reference/api/vue/ColumnText.md); [`ColumnModelLink`](/v3/reference/api/vue/ColumnModelLink.md)
- Described in: [Customize List Column Rendering](/v3/guides/customize-list-column-rendering.md#choose-where-to-override)

## Column Totals

Per-column sums that a `list` response returns in `columnTotals`, computed over every row that the filters and [Row-Level Permissions](/v3/reference/glossary.md#row-level-permissions) leave, across all pages. Only a paginated response carries them. A viewset declares them in `column_totals`, and a request names the ones it wants in the `ct` query parameter.

- Names: [`column_totals`](/v3/reference/api/py/vueda.core.viewsets/ListRowLevelViewSetMixin.md#column_totals); [`COLUMN_TOTALS_PARAM`](/v3/reference/api/js/utils/constants.md#COLUMN_TOTALS_PARAM); [`model_column_totals`](/v3/reference/api/py/vueda.info.serializers/ModelInfoSerializer.md#get_model_column_totals); [`ModelInfo.columnTotals`](/v3/reference/api/js/stores/storeModelInfo/types/ModelInfo.md#columnTotals); [`totalables`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#totalables)
- Described in: [Expose Aggregates in `list` Responses](/v3/guides/list-column-totals.md)
- Upstream: [Django: `QuerySet.aggregate`](https://docs.djangoproject.com/en/6.1/ref/models/querysets/#django.db.models.query.QuerySet.aggregate)

## Composite Primary Key

A primary key made of several model fields, declared with Django's `CompositePrimaryKey`. VUEDA sends its value as a JSON array string, such as `["1", "42"]`, and reads that string from the pk segment of a detail URL.

- Names: [`CompositePrimaryKeyField`](/v3/reference/api/py/vueda.core.serializers.fields/CompositePrimaryKeyField.md); [`VuedaCompositePrimaryKeyFilterSet`](/v3/reference/api/py/vueda.core.filters/VuedaCompositePrimaryKeyFilterSet.md)
- Described in: [Set Up CRUD for a Composite Primary Key Model](/v3/guides/composite-primary-keys.md)
- Upstream: [Django: `CompositePrimaryKey`](https://docs.djangoproject.com/en/6.1/ref/models/fields/#django.db.models.CompositePrimaryKey)

## Composition Primitive

An underscore-prefixed [Theme Key](/v3/reference/glossary.md#theme-key), such as `_ButtonBase`, that styles no component on its own. A [Theme Slot](/v3/reference/glossary.md#theme-slot) lists primitive slots in its `composes` array and takes their classes before its own. A change to one primitive reaches every slot that composes it.

- Names: `composes`; example [`_ButtonBase`](/v3/reference/theming/keys/_ButtonBase.md); [`ComponentTheme`](/v3/reference/api/js/use/useTheme/types/ComponentTheme.md)
- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#family-meta-keys)

## Computed Field

A form field that always renders in `FormField`, outside the [Form Context](/v3/reference/glossary.md#form-context). It renders read-only unless `fieldProps` sets `readOnly: false` for it. You name computed fields in the model config's `computedFields` list or the form's `computedFields` prop, which replaces the list.

- Names: [`computedFields` prop](/v3/reference/api/vue/FormModel.md#prop-computedFields); [`computedFields` config](/v3/reference/api/js/stores/storeModelConfig/types/OverridingModelConfig.md#computedFields)
- Described in: [Contract-First Dynamic UI](/v3/core-concepts/contract-first-dynamic-ui.md#exceptions)

## Content Type

Django's `ContentType` row, which identifies a model by its `app_label` and model name. VUEDA uses content types to identify the model behind model info, permissions, and workflows. They also identify the record that a queue item links to.

- Described in: [Canonical Registration and Model Discovery](/v3/core-concepts/canonical-registration-and-discovery.md)
- Upstream: [Django: `ContentType`](https://docs.djangoproject.com/en/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType)

## CRUD

VUEDA's five permission and action names: `create`, `read`, `update`, `delete`, and `list`. VUEDA adds `list` to each model's default permissions unless the model declares its own `default_permissions`. Codenames take the form `<app_label>.<name>_<model_name>`, such as `vueda_vdq.list_queueitem`. Client routes use these names. On the server, `read` covers every `GET` except `list`, `update` also covers `partial_update`, and `delete` covers `destroy`.

- Names: [`BaseModelMeta.default_permissions`](/v3/reference/api/py/vueda.core.models/BaseModelMeta.md#default_permissions); [`ObjectPermissions.perms_map`](/v3/reference/api/py/vueda.core.permissions/ObjectPermissions.md#perms_map); [`getActionName`](/v3/reference/api/js/utils/actionMap/functions/getActionName.md)
- Described in: [Permission Model](/v3/core-concepts/permission-model.md#crud-codename-and-action-mapping)
- Upstream: [Django: `default_permissions`](https://docs.djangoproject.com/en/6.1/ref/models/options/#django.db.models.Options.default_permissions)

## CRUD Adapter

A function that performs one data operation, such as retrieve, update, or delete, for the reactive-helpers list and object composables. The adapters cover list operations too: list, bulk delete, and actions on several objects. `setupDefaultListCrud` and `setupDefaultObjectCrud` register VUEDA's REST adapters, and you can replace any of them.

- Names: [`setupDefaultListCrud`](/v3/reference/api/js/utils/listCrud/functions/setupDefaultListCrud.md); [`setupDefaultObjectCrud`](/v3/reference/api/js/utils/objectCrud/functions/setupDefaultObjectCrud.md)
- Described in: [CRUD Adapter Layer](/v3/core-concepts/crud-adapter-layer.md)
- Upstream: [reactive-helpers: `setListCrud`](https://reactive-helpers.arrai.dev/v25/reference/api/config/listCrud.html#setlistcrud); [reactive-helpers: `setObjectCrud`](https://reactive-helpers.arrai.dev/v25/reference/api/config/objectCrud.html#setobjectcrud)

## CRUD Routes

The two client routes that `makeCRUDRoutes` registers for every model and action. The detail route, `/:app/:model/:action/:pk`, targets one object; the list route, `/:app/:model/:action/`, targets a model or the objects in its `pk` query value. Either route may carry a `returnPath` query value, where an action view goes after it succeeds or the user cancels it.

- Names: [`makeCRUDRoutes`](/v3/reference/api/js/router/makeCrud/functions/makeCRUDRoutes.md); [`getCRUDForTo`](/v3/reference/api/js/router/getCrud/functions/getCRUDForTo.md); `actionrouter.detailview`; `actionrouter.listview`
- Described in: [Routing and View Resolution Model](/v3/core-concepts/routing-and-view-resolution-model.md#route-records-and-names)

## CRUDL

`create`, `read`, `update`, `delete`, `list` permission/action vocabulary used by VUEDA.

## CRUDL Routes

The two client routes that [`makeCRUDRoutes`](/v3/reference/api/js/router/makeCrud/functions/makeCRUDRoutes.md) registers: a detail route at `/:app/:model/:action/:pk` for one object, and a list route at `/:app/:model/:action/` that takes comma-separated primary keys as the `pk` query value for a bulk action. Either route may carry a `returnPath` query value, where an action view goes after it finishes.

## CRUDL View Resolution

The client-side mechanism that maps each CRUDL action to a Vue component via `setCrudComponents`, with `ViewActionRouter` selecting the correct component at render time.

## Customization Scope

How much of the UI one theming change reaches. The four scopes are instance ([Theme Override](/v3/reference/glossary.md#theme-override)), component ([Theme Key](/v3/reference/glossary.md#theme-key)), family ([Composition Primitive](/v3/reference/glossary.md#composition-primitive)), and brand ([Theme Token](/v3/reference/glossary.md#theme-token)). Pick the narrowest scope that covers your change.

- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#the-four-scopes)

## Done State

A [Queue Item](/v3/reference/glossary.md#queue-item) workflow state that ends processing: `cancelled`, `succeeded`, or `unconfirmed`. The queue list hides items in a done state, and [Sent Item](/v3/reference/glossary.md#sent-item) endpoints show only them. `errored` is not a done state, so an errored item stays in the queue.

- Names: `QUEUE_ITEM_DONE_STATES` in [`vueda.vdq.constants`](/v3/reference/api/py/vueda.vdq.constants.md)
- Described in: [VDQ and Background Work Model](/v3/core-concepts/vdq-and-background-work.md#done-state-semantics-and-cleanup-gating)

## Dry Run

A request mode, set with the `Dry-Run: true` header, that validates a write and keeps none of its database changes. An extra action declared with VUEDA's `action` decorator runs its body, and the server then rolls back the database transaction. Work outside the database still runs. `destroy` runs its checks and deletes nothing. The other built-in writes ignore the header.

- Names: the `Dry-Run` header; `DRY_RUN_HEADER`; [`action`](/v3/reference/api/py/vueda.core.decorators.md#action); [`dryRun`](/v3/reference/api/js/use/useModelAction/types/ModelActionRunOptions.md#dryRun)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#dry-run-and-mutation-semantics)
- Upstream: [Django: `set_rollback`](https://docs.djangoproject.com/en/6.1/topics/db/transactions/#django.db.transaction.set_rollback)

## Expand

A request option that returns a related object inline in place of its primary key. You name relations in the `e` query parameter, choosing from the ones the serializer declares and [Model Info](/v3/reference/glossary.md#model-info) lists. The action's [Action-Scoped Expand](/v3/reference/glossary.md#action-scoped-expand) list narrows that choice. On a write, a relation named in `e` also accepts a nested object, for a [Nested Write](/v3/reference/glossary.md#nested-write).

- Names: [`EXPAND_PARAM`](/v3/reference/api/js/utils/constants.md#EXPAND_PARAM); `expandable_fields`; [`model_expands`](/v3/reference/api/py/vueda.info.serializers/ModelInfoSerializer.md#get_model_expands); [`ModelInfo.expand`](/v3/reference/api/js/stores/storeModelInfo/types/ModelInfo.md#expand); [`ModelConfig.expand`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#expand); [`FlexFieldsWriteableNestedSerializerMixin`](/v3/reference/api/py/vueda.core.serializers/FlexFieldsWriteableNestedSerializerMixin.md)
- Described in: [Field and Expand Semantics](/v3/core-concepts/field-and-expand-semantics.md#parameter-namespace-and-wire-shape)
- Upstream: [drf-flex-fields2: `FlexFieldsSerializerMixin`](https://drf-flex-fields2.readthedocs.io/en/stable/api/rest_flex_fields2/serializers/FlexFieldsSerializerMixin.html#rest_flex_fields2.serializers.FlexFieldsSerializerMixin)

## Extra Action

An [Action](/v3/reference/glossary.md#action) that a viewset declares with VUEDA's `action` decorator, in addition to the built-in actions. It targets one object when declared `detail=True` and the model otherwise; a [Bulk Action](/v3/reference/glossary.md#bulk-action) can target several objects. Model info reports it by its `url_name`.

- Names: [`action`](/v3/reference/api/py/vueda.core.decorators.md#action); [`detail`](/v3/reference/api/py/vueda.core.decorators.md#action-param-detail); [`get_allowed_extra_actions`](/v3/reference/api/py/vueda.core.viewsets/VuedaViewSet.md#get_allowed_extra_actions)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#server-action-declaration-and-route-partitioning)
- Upstream: [DRF: `action`](https://www.django-rest-framework.org/api-guide/viewsets/#marking-extra-actions-for-routing)

## Fast Transition

A [Transition](/v3/reference/glossary.md#transition) that server code applies through `fast_transition`. It checks only that the current state is a source for the transition, skips permission checks, and records the change under the system user. From a source marked ignored, it keeps the state and runs `on_transition_ignored`; [VDQ](/v3/reference/glossary.md#vdq-vueda-dispatch-queue) uses this for late provider callbacks.

- Names: [`fast_transition`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#fast_transition); [`TransitionSource.ignored`](/v3/reference/api/py/vueda.workflow.models/TransitionSource.md#ignored); [`on_transition_ignored`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#on_transition_ignored)
- Described in: [VDQ and Background Work Model](/v3/core-concepts/vdq-and-background-work.md#workflow-backed-lifecycle-including-ignored-transitions)

## Feature Policy

A [VUEDA Model](/v3/reference/glossary.md#vueda-model)'s per-feature settings, declared in a nested `class Vueda` with one inner class per feature, such as `History` or `Workflow`. Options a model leaves out take the feature app's defaults, and declarations inherit through the model's bases.

- Names: `class Vueda`; [`get_vueda_options`](/v3/reference/api/py/vueda.core.options.md#get_vueda_options); [`register_feature_section`](/v3/reference/api/py/vueda.core.features.md#register_feature_section)
- Described in: [Model Feature Policy](/v3/core-concepts/model-feature-policy.md)
- Upstream: [Django: `class_prepared`](https://docs.djangoproject.com/en/6.1/ref/signals/#django.db.models.signals.class_prepared)

## Field Path

The key that names one field in a form, with dots for nested objects and brackets for list items, such as `address.city` or `items[0].quantity`. The [Form Context](/v3/reference/glossary.md#form-context) and the client's parsed server errors key fields by it.

- Names: [`FormValidationError`](/v3/reference/api/js/utils/errors/members/FormValidationError.md)
- Described in: [Error and Validation Contract](/v3/core-concepts/error-and-validation-contract.md#non-field-and-nested-path-semantics)

## Field Subset (`fields`)

Contract option to request a sparse response containing selected fields.

## Form Context

The shared form state and methods that `useForm` provides to the fields inside a form: values, errors, messages, and touched and ignored fields. Each field calls `useField`, which creates a field context that reads and writes the form context at the field's [Field Path](/v3/reference/glossary.md#field-path).

- Names: [`useForm`](/v3/reference/api/js/use/useForm/functions/useForm.md); [`FormContext`](/v3/reference/api/js/use/useForm/types/FormContext.md); [`useField`](/v3/reference/api/js/use/useField/functions/useField.md); [`FieldContext`](/v3/reference/api/js/use/useField/types/FieldContext.md)
- Described in: [Form State and Validation Lifecycle](/v3/core-concepts/form-state-and-validation-lifecycle.md#form-context-state-shape)

## Form Field

The component that renders one field's label, help text, and error and warning messages around its [Widget](/v3/reference/glossary.md#widget). VUEDA picks it from the form's `fieldComponents` prop, then the model config's `fieldComponents`, then the default. The default is `FormField`, or an [Inline](/v3/reference/glossary.md#inline) for an expanded relation. A [Computed Field](/v3/reference/glossary.md#computed-field) always uses `FormField`.

- Names: [`FormField`](/v3/reference/api/vue/FormField.md); [`fieldComponents` prop](/v3/reference/api/vue/FormModel.md#prop-fieldComponents); [`ModelConfig.fieldComponents`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#fieldComponents); [`FIELD_PROPS`](/v3/reference/api/js/use/useField.md#FIELD_PROPS); [`availableFields`](/v3/reference/api/js/utils/formLookups.md#availableFields)
- Described in: [Contract-First Dynamic UI](/v3/core-concepts/contract-first-dynamic-ui.md#field-and-widget-resolution)

## Formatted Name

The display label each [VUEDA Model](/v3/reference/glossary.md#vueda-model) exposes as `formatted_name`, which the client shows for related objects and choices. By default it is a stored generated column that copies the model's `name` field. A model can instead supply it through another expression, a lookup path, or a `get_formatted_name()` method.

- Names: [`formatted_name`](/v3/reference/api/py/vueda.core.models/FormattedNameBaseModel.md#formatted_name); [`formatted_name_lookup_expression`](/v3/reference/api/py/vueda.core.models/FormattedNameBaseModel.md#formatted_name_lookup_expression); `get_formatted_name()`
- Described in: [Create a CRUD Surface for a New Model](/v3/guides/create-crud-surface.md#the-formatted-name-contract)
- Upstream: [Django: `GeneratedField`](https://docs.djangoproject.com/en/6.1/ref/models/fields/#django.db.models.GeneratedField)

## Group Management Page

A page, served only when `DEBUG` is on, where you rename groups and add or remove the permissions each group holds. VUEDA records each change for a [Group Permission Migration](/v3/reference/glossary.md#group-permission-migration).

- Names: [`PermissionOverviewView`](/v3/reference/api/py/vueda.user.views/PermissionOverviewView.md)
- Described in: [Manage Groups and Generate Group Migrations](/v3/guides/manage-groups.md#group-management-ui)

## Group Permission Migration

A migration that `makegroupmigrations` writes from the changes recorded on the [Group Management Page](/v3/reference/glossary.md#group-management-page), so other environments receive the same group permissions. It names groups and permissions by natural key and goes in the app of `AUTH_USER_MODEL`.

- Names: [`makegroupmigrations`](/v3/reference/api/py/vueda.user.management.commands.makegroupmigrations/Command.md); [`updategroupmigrations`](/v3/reference/api/py/vueda.user.management.commands.updategroupmigrations/Command.md); [`sync_group_changes`](/v3/reference/api/py/vueda.user.management.commands.sync_group_changes/Command.md); [`GroupChange`](/v3/reference/api/py/vueda.user.models/GroupChange.md)
- Described in: [Manage Groups and Generate Group Migrations](/v3/guides/manage-groups.md#generating-group-migrations)
- Upstream: [Django: `Group`](https://docs.djangoproject.com/en/6.1/ref/contrib/auth/#django.contrib.auth.models.Group); [Django: `AUTH_USER_MODEL`](https://docs.djangoproject.com/en/6.1/ref/settings/#std-setting-AUTH_USER_MODEL)

## Hairline

VUEDA's edge line for controls and surfaces. Its width comes from the `--vueda-hairline-width` token, which steps down as screen pixel density rises. The `hairline` utility paints it as an inset shadow, so a four-sided edge adds no layout width.

- Names: [`--vueda-hairline-width`](/v3/reference/theming/tokens/base.md#css-token-vueda-hairline-width); the `hairline` utility
- Described in: [Customize VUEDA Appearance](/v3/guides/customize-vueda-appearance.md#common-pitfalls)

## Icon Registry

The registry that maps icon names, such as `loading` or `check`, to Vue components, grouped by component name. It starts empty. You fill it with `setIcons` or `patchIcons`, for example by installing the Font Awesome Free preset.

- Names: [`setIcons`](/v3/reference/api/js/use/useIcons/functions/setIcons.md); [`patchIcons`](/v3/reference/api/js/use/useIcons/functions/patchIcons.md); [`useIcons`](/v3/reference/api/js/use/useIcons/functions/useIcons.md); [`useIconsOverride`](/v3/reference/api/js/use/useIcons/functions/useIconsOverride.md); [`IconRegistry`](/v3/reference/api/js/use/useIcons/types/IconRegistry.md); [`installFontAwesomeFreeIcons`](/v3/reference/api/js/theme/vueda-tailwind/icons/fontAwesomeFree/functions/installFontAwesomeFreeIcons.md)
- Described in: [Client Plugin Prerequisites](/v3/guides/client-plugin-prerequisites.md#register-the-icons)

## Ignored Field

A [Field Path](/v3/reference/glossary.md#field-path) marked with the form context's `ignore` method. The form leaves an ignored field out of the values it submits. In an object form, errors on an ignored path do not block submitting. An [Inline](/v3/reference/glossary.md#inline) ignores each saved row you mark for removal.

- Names: [`FormContext.ignore`](/v3/reference/api/js/use/useForm/types/FormContext.md#ignore); [`FieldContext.ignore`](/v3/reference/api/js/use/useField/types/FieldContext.md#ignore); [`submittingValues`](/v3/reference/api/js/use/useForm/types/FormContextRawState.md#submittingValues)
- Described in: [Form State and Validation Lifecycle](/v3/core-concepts/form-state-and-validation-lifecycle.md#ignored-fields-and-submitting-values)

## Inline

A field set that edits related objects inside the parent form. `FieldSetTabularInline` shows them as table rows and `FieldSetStackedInline` as stacked cards. Saving the parent sends them in a [Nested Write](/v3/reference/glossary.md#nested-write).

- Names: [`FieldSetTabularInline`](/v3/reference/api/vue/FieldSetTabularInline.md); [`FieldSetStackedInline`](/v3/reference/api/vue/FieldSetStackedInline.md); [`useFieldSetInline`](/v3/reference/api/js/use/useFieldSetInline/functions/useFieldSetInline.md)
- Described in: [Build Nested/Inlined Writes](/v3/guides/nested-writable-inlines.md)

## Integrator

A team integrating VUEDA into a domain application.

## List Scope

A constraint on a list that a link or your application code supplies, shown as a chip with no editable input. It comes from a hidden filter's value in the URL, or from a `params` key you declare in the `scopes` option.

- Names: [`scopes`](/v3/reference/api/vue/ViewList.md#prop-scopes); [`params`](/v3/reference/api/vue/ViewList.md#prop-params); [`FilterInfo.hidden`](/v3/reference/api/js/stores/storeModelInfo/types/FilterInfo.md#hidden); [`ViewListScope`](/v3/reference/api/js/use/useViewList/types/ViewListScope.md); [`ScopeChip`](/v3/reference/api/vue/ScopeChip.md); [`ScopeGroup`](/v3/reference/api/vue/ScopeGroup.md)
- Described in: [Open a Scoped List](/v3/guides/scope-a-list.md)

## Lookup

An abstract model base for reference tables of codes and names, such as statuses or categories. It provides a unique `code`, a `name`, and a [Formatted Name](/v3/reference/glossary.md#formatted-name). It is a [VUEDA Model](/v3/reference/glossary.md#vueda-model) base.

- Names: [`Lookup`](/v3/reference/api/py/vueda.core.models/Lookup.md); [`VuedaLookupSerializer`](/v3/reference/api/py/vueda.core.serializers/VuedaLookupSerializer.md)
- Described in: [Choice-Backed Fields and Lookup Models](/v3/guides/choices-and-lookups.md#declare-a-lookup-model)
- Upstream: [Django: abstract base classes](https://docs.djangoproject.com/en/6.1/ref/models/options/#django.db.models.Options.abstract)

## Model Actions

The `model_actions` list in [Model Info](/v3/reference/glossary.md#model-info): the actions the model's viewset offers the current user, with no object in view. Built-in actions appear when a [Model-Scope Check](/v3/reference/glossary.md#model-scope-check) passes; extra actions appear when `get_allowed_extra_actions` includes them. The list shapes client routes and buttons, and each endpoint still enforces its own permissions.

- Names: `model_actions`; [`get_model_actions`](/v3/reference/api/py/vueda.info.serializers/ModelInfoSerializer.md#get_model_actions); [`ModelInfoAction`](/v3/reference/api/rest/schemas/ModelInfoAction.md); [`ModelInfo.actions`](/v3/reference/api/js/stores/storeModelInfo/types/ModelInfo.md#actions)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#model-scope-action-metadata)

## Model API Path

The server path the client requests for a model's endpoints: `/routes/<app_label>/<model_name>/`, with detail and action paths below it. You serve each viewset there, or change the client's URL templates with `setCustomUrl`.

- Names: [`getListUrl`](/v3/reference/api/js/utils/urls/functions/getListUrl.md); [`getDetailUrl`](/v3/reference/api/js/utils/urls/functions/getDetailUrl.md); [`setCustomUrl`](/v3/reference/api/js/utils/urls/functions/setCustomUrl.md); [`VuedaRouter`](/v3/reference/api/py/vueda.core.routers/VuedaRouter.md); `modelList`; `modelDetail`; `modelAction`; `modelDetailAction`
- Described in: [Create a CRUD Surface for a New Model](/v3/guides/create-crud-surface.md#router-and-url-wiring)
- Upstream: [Django: `Options.app_label`](https://docs.djangoproject.com/en/6.1/ref/models/options/#django.db.models.Options.app_label)

## Model Config

The client's settings for a model's views, built from [Model Info](/v3/reference/glossary.md#model-info) and the overrides you pass to `setConfig`. Overrides have a generic layer for every view and a per-view layer keyed by view name. For the same key, the per-view layer wins.

- Names: [`storeModelConfig`](/v3/reference/api/js/stores/storeModelConfig/functions/storeModelConfig.md); [`setConfig`](/v3/reference/api/js/stores/storeModelConfig/methods/setConfig.md); [`useModelConfig`](/v3/reference/api/js/use/useModelConfig/functions/useModelConfig.md); [`OverridingModelConfig`](/v3/reference/api/js/stores/storeModelConfig/types/OverridingModelConfig.md)
- Described in: [Contract-First Dynamic UI](/v3/core-concepts/contract-first-dynamic-ui.md#configuration-precedence)

## Model History

The record of inserts, updates, and deletes that VUEDA keeps for each tracked model, stored as pghistory event rows. VUEDA tracks every managed [VUEDA Model](/v3/reference/glossary.md#vueda-model) unless its [Feature Policy](/v3/reference/glossary.md#feature-policy) sets `History.enabled = False`. Event rows are append-only, and VUEDA sets no retention policy.

- Names: [`vueda.history`](/v3/reference/api/py/vueda.history.md); `History.enabled`; `PGHISTORY_APPEND_ONLY`
- Described in: [Model Feature Policy](/v3/core-concepts/model-feature-policy.md#history-and-workflow); [Model History Response](/v3/core-concepts/model-history-response.md)
- Upstream: [pghistory: `track`](https://django-pghistory.readthedocs.io/en/3.9.2/module/#pghistory.track); [pghistory: `Event`](https://django-pghistory.readthedocs.io/en/3.9.2/module/#pghistory.models.Event)

## Model Info

The metadata the server publishes for each registered model, in seven sections: fields, actions, expands, ordering, filtering, column totals, and permissions. The actions section depends on the requesting user. The client builds its default views from model info and caches it per model.

- Names: [Get model info](/v3/reference/api/rest/vueda.info/vueda.info_model_info_retrieve.md); [`ModelInfoSerializer`](/v3/reference/api/py/vueda.info.serializers/ModelInfoSerializer.md); [`storeModelInfo`](/v3/reference/api/js/stores/storeModelInfo/functions/storeModelInfo.md); [`useModelInfo`](/v3/reference/api/js/use/useModelInfo/functions/useModelInfo.md); [`ModelInfo`](/v3/reference/api/js/stores/storeModelInfo/types/ModelInfo.md)
- Described in: [Server-Client Metadata Contract](/v3/core-concepts/server-client-metadata-contract.md#metadata-sections)

## Model-Scope Check

A permission check with no object, which asks whether the user may perform an action on the model at all. The server runs it before a request fetches any object, and it runs one for each built-in action to build [Model Actions](/v3/reference/glossary.md#model-actions).

- Names: [`check_action_permission`](/v3/reference/api/py/vueda.core.permissions.md#check_action_permission)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#model-scope-action-metadata)

## Model-Scope Deferral

On a [Workflow-Enabled Model](/v3/reference/glossary.md#workflow-enabled-model), the server can hold a model-scope denial open. It does so when a [State Permission](/v3/reference/glossary.md#state-permission) rule grants the codename to one of the user's groups. It applies only where a later object check or list filter decides the request; `create` keeps the denial. This is server enforcement.

- Names: [`has_matching_state_grant`](/v3/reference/api/py/vueda.core.permissions.md#has_matching_state_grant); [`ObjectPermissions.has_permission`](/v3/reference/api/py/vueda.core.permissions/ObjectPermissions.md#has_permission); [`object_permission_actions`](/v3/reference/api/py/vueda.core.permissions/ObjectPermissions.md#object_permission_actions); [`workflow_object_permission_actions`](/v3/reference/api/py/vueda.core.viewsets/VuedaViewSet.md#workflow_object_permission_actions)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#model-scope-deferral-and-later-decisions)

## Model-Scope vs Object-Scope Availability

The contract distinction where `model_actions` advertises model-level action availability and `available_actions` reports per-object availability.

## Nested Write

A create or update that sends related objects inside the parent payload and saves them in the same request. A relation accepts nested objects when its serializer field is a nested serializer or the request names it in [Expand](/v3/reference/glossary.md#expand).

- Names: [`FlexFieldsWriteableNestedSerializerMixin`](/v3/reference/api/py/vueda.core.serializers/FlexFieldsWriteableNestedSerializerMixin.md); [`VuedaSerializer`](/v3/reference/api/py/vueda.core.serializers/VuedaSerializer.md)
- Described in: [Nested Write Compatibility](/v3/core-concepts/nested-write-compatibility.md)
- Upstream: [drf-writable-nested: `NestedCreateMixin`](https://github.com/beda-software/drf-writable-nested#drf-writable-nested); [drf-writable-nested: `NestedUpdateMixin`](https://github.com/beda-software/drf-writable-nested#drf-writable-nested); [drf-flex-fields2: `FlexFieldsSerializerMixin`](https://drf-flex-fields2.readthedocs.io/en/stable/api/rest_flex_fields2/serializers/FlexFieldsSerializerMixin.html#rest_flex_fields2.serializers.FlexFieldsSerializerMixin)

## Non-Field Error

A validation error or warning that belongs to the whole form, sent under the `non_field_errors` key. VUEDA's exception handler also puts a validation error raised as a list under that key. `FormMessage` renders these messages in the form.

- Names: [`NON_FIELD_ERRORS_KEY`](/v3/reference/api/js/utils/constants.md#NON_FIELD_ERRORS_KEY); [`debug_stack_exception_handler`](/v3/reference/api/py/vueda.core.exceptions.md#debug_stack_exception_handler); [`FormMessage`](/v3/reference/api/vue/FormMessage.md)
- Described in: [Error and Validation Contract](/v3/core-concepts/error-and-validation-contract.md#non-field-and-nested-path-semantics)
- Upstream: [DRF: `ValidationError`](https://www.django-rest-framework.org/api-guide/exceptions/#validationerror); [Django: `NON_FIELD_ERRORS`](https://docs.djangoproject.com/en/6.1/ref/exceptions/#django.core.exceptions.NON_FIELD_ERRORS)

## Object State

The record that stores which workflow state one object is in. VUEDA creates it in the workflow's initial state when a save of a [Workflow-Enabled Model](/v3/reference/glossary.md#workflow-enabled-model) object finds none. A raw save, such as a fixture load, creates none. `backfillworkflowstates` creates any that are missing.

- Names: [`ObjectState`](/v3/reference/api/py/vueda.workflow.models/ObjectState.md); [`workflow_state`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#workflow_state); [`ensure_object_state`](/v3/reference/api/py/vueda.workflow.models.md#ensure_object_state); [`backfillworkflowstates`](/v3/reference/api/py/vueda.workflow.management.commands.backfillworkflowstates/Command.md)
- Described in: [Manage Workflows and Generate Workflow Migrations](/v3/guides/manage-workflows.md#enabling-workflow-on-a-model-with-existing-rows)

## Object-Scope Check

A permission check against one object, including its [Row-Level Permissions](/v3/reference/glossary.md#row-level-permissions) and [State Permission](/v3/reference/glossary.md#state-permission) rules. The server runs it on requests for that object, and it decides which built-in actions appear in the object's [Available Actions](/v3/reference/glossary.md#available-actions).

- Names: [`check_action_permission`](/v3/reference/api/py/vueda.core.permissions.md#check_action_permission); [`ObjectPermissions`](/v3/reference/api/py/vueda.core.permissions/ObjectPermissions.md)
- Described in: [Action Contract and Availability](/v3/core-concepts/action-contract-and-availability.md#object-scope-availability-metadata)

## Permission Layers

The checks `VUEDAPermissionsMixin.has_perm` runs for a permission, in order: the [Baseline Permission](/v3/reference/glossary.md#baseline-permission), [State Permission](/v3/reference/glossary.md#state-permission) rules, `check_instance`, and `check_instance_workflow`. Each layer that returns an answer replaces the decision so far, except that a state deny skips `check_instance`. Superusers pass before any layer runs; this is server enforcement.

- Names: [`VUEDAPermissionsMixin.has_perm`](/v3/reference/api/py/vueda.user.mixins/VUEDAPermissionsMixin.md#has_perm); [`check_instance`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_instance); [`check_instance_workflow`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_instance_workflow)
- Described in: [Permission Model](/v3/core-concepts/permission-model.md#permission-authority-layers)
- Upstream: [Django: `PermissionsMixin.has_perm`](https://docs.djangoproject.com/en/6.1/topics/auth/customizing/#django.contrib.auth.models.PermissionsMixin.has_perm)

## Permission Mapping

The `PERMISSION_NAMES_MAPPING` setting, which maps Django's permission action names to VUEDA's. By default `add` becomes `create`, `change` becomes `update`, and `view` becomes `read`. It takes effect when your settings import `vueda.core.patch_django` after setting it.

- Names: `PERMISSION_NAMES_MAPPING`; [`patch_django`](/v3/reference/api/py/vueda.core.patch_django.md); [`get_builtin_permissions`](/v3/reference/api/py/vueda.core.patch_django.md#get_builtin_permissions); [`get_permission_codename`](/v3/reference/api/py/vueda.core.patch_django.md#get_permission_codename)
- Described in: [Map Django and VUEDA Permission Names](/v3/guides/permission-name-mapping.md#set-mapping-and-patch-import-order)
- Upstream: [Django: `default_permissions`](https://docs.djangoproject.com/en/6.1/ref/models/options/#django.db.models.Options.default_permissions)

## Permissions and Workflow Overview

A read-only page, served only when `DEBUG` is on, that lists each registered model's permissions and the groups that hold them. It also lists each workflow's transitions, workflow permissions, and state rules, and can show what one selected user holds. You edit groups on the [Group Management Page](/v3/reference/glossary.md#group-management-page).

- Names: [`InfoOverviewView`](/v3/reference/api/py/vueda.info.views/InfoOverviewView.md)
- Described in: [Use the Permissions and Workflow Overview](/v3/guides/permissions-workflow-overview.md)

## Permitted Transitions

The transitions of a model's [Workflow](/v3/reference/glossary.md#workflow) that the current user may execute, computed at model scope with no object. The client uses them for [Route Admission](/v3/reference/glossary.md#route-admission) and for transition buttons on list views. Executing one still checks the object and its current state on the server.

- Names: [`permitted_transitions`](/v3/reference/api/py/vueda.workflow.viewsets/WorkflowViewSet.md#permitted_transitions); [`GET permitted_transitions/`](/v3/reference/api/rest/vueda.workflow/vueda.workflow_workflows_permitted_transitions_list.md); [`fetchWorkflowTransition`](/v3/reference/api/js/stores/storeWorkflow/methods/fetchWorkflowTransition.md)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#which-gate-each-workflow-endpoint-applies)

## Pk Marker

The `pk: true` flag that [Model Info](/v3/reference/glossary.md#model-info) sets on the field whose name matches the model's primary key. The client reads it to find each object's identifier, and fails to load the model's metadata when no field carries it.

- Names: [`FieldInfo.pk`](/v3/reference/api/js/stores/storeModelInfo/types/FieldInfo.md#pk); [`ModelInfo.pk`](/v3/reference/api/js/stores/storeModelInfo/types/ModelInfo.md#pk); [`get_model_fields_data`](/v3/reference/api/py/vueda.info.serializers/ModelInfoSerializer.md#get_model_fields_data)
- Described in: [Primary Key and Identifier Discipline](/v3/core-concepts/pk-and-identifier-discipline.md#pk-authority-and-metadata-source)
- Upstream: [Django: `Field.primary_key`](https://docs.djangoproject.com/en/6.1/ref/models/fields/#django.db.models.Field.primary_key)

## Public Name

The dotted path that a request uses for a field, filter, ordering term, or expand, such as `customer.formatted_name`. For ordering terms and declared filters, the server keeps the `__`-joined Django path internal, so a request names them by public name, never by ORM path.

- Names: [`vueda.core.paths`](/v3/reference/api/py/vueda.core.paths.md); [`PublicFilterAliasMixin`](/v3/reference/api/py/vueda.core.filters/PublicFilterAliasMixin.md); [`public_ordering_path_to_orm`](/v3/reference/api/py/vueda.core.paths.md#public_ordering_path_to_orm); [`orm_filter_path_to_public`](/v3/reference/api/py/vueda.core.paths.md#orm_filter_path_to_public)
- Described in: [Filtering and Ordering Semantics](/v3/core-concepts/filtering-and-ordering-semantics.md#public-filter-names)
- Upstream: [django-filter: `FilterSet`](https://django-filter.readthedocs.io/en/stable/ref/filterset.html#django_filters.filterset.FilterSet)

## Query Parameter Validation

The server's rejection of query parameters that a request does not recognize. A `list` or `retrieve` request rejects an unknown key. A `list`, `retrieve`, `create`, `update`, or `partial_update` request rejects an `f` or `e` value that the endpoint does not offer. Each rejection returns a validation error that names the parameter or value.

- Names: [`NoExtraFieldsForViewSetMixin`](/v3/reference/api/py/vueda.core.viewsets/NoExtraFieldsForViewSetMixin.md); [`get_extra_allowed_fields`](/v3/reference/api/py/vueda.core.viewsets/NoExtraFieldsForViewSetMixin.md#get_extra_allowed_fields); [`reject_unrecognized_query_params`](/v3/reference/api/py/vueda.core.viewsets/NoExtraFieldsForViewSetMixin.md#reject_unrecognized_query_params); [`validate_flex_expand_and_field_param`](/v3/reference/api/py/vueda.core.viewsets/NoExtraFieldsForViewSetMixin.md#validate_flex_expand_and_field_param)
- Described in: [Filtering and Ordering Semantics](/v3/core-concepts/filtering-and-ordering-semantics.md#query-namespace-and-validation-boundary)

## Queue Item

The database row for one [VDQ (VUEDA Dispatch Queue)](/v3/reference/glossary.md#vdq-vueda-dispatch-queue) message to one receiver. It holds the sender, receiver, method (`email` or `sms`), and send result, and an [Object State](/v3/reference/glossary.md#object-state) holds its workflow state. `add_email` creates one queue item per `to`, `cc`, and `bcc` address.

- Names: [`QueueItem`](/v3/reference/api/py/vueda.vdq.models/QueueItem.md); [`AnyMailQueueItem`](/v3/reference/api/py/vueda.vdq.models/AnyMailQueueItem.md); [`SMSQueueItem`](/v3/reference/api/py/vueda.vdq.models/SMSQueueItem.md); [`add_email`](/v3/reference/api/py/vueda.vdq.schedulers.md#add_email); [`add_sms`](/v3/reference/api/py/vueda.vdq.schedulers.md#add_sms); [queue item endpoint](/v3/reference/api/rest/vueda.vdq/vueda.vdq_queueitem_list.md); [`DefaultQueueItem`](/v3/reference/api/rest/schemas/DefaultQueueItem.md)
- Described in: [VDQ and Background Work Model](/v3/core-concepts/vdq-and-background-work.md#persistence-and-workflow-boundary)

## Queue Item (VDQ)

The persistent work record in VDQ that tracks one queued send operation, its workflow state, and processing metadata.

## Reauthentication

A check that a signed-in user confirmed their identity recently. The account decides which confirmation counts: a code for a user with a two-factor device, the password otherwise. The server enforces the check on sensitive actions, such as two-factor device setup. In the client, `requireRecentAuth` and the auth views route the user to the `reauthenticate` page and back.

- Names: [`recent_auth_required`](/v3/reference/api/py/vueda.core.decorators.md#recent_auth_required); [`auth_pending_flow`](/v3/reference/api/py/vueda.user.serializers/WhoIsSerializer.md); `authPendingFlow`; [`requireRecentAuth`](/v3/reference/api/js/router/guards/functions/requireRecentAuth.md); [`storeUser.reauthenticate`](/v3/reference/api/js/stores/storeUser/methods/reauthenticate.md); [`storeUser.twoFactorReauthenticate`](/v3/reference/api/js/stores/storeUser/methods/twoFactorReauthenticate.md); [reauthenticate endpoint](/v3/reference/api/rest/vueda.user/vueda.user_reauthenticate_create.md); [two-factor reauthenticate endpoint](/v3/reference/api/rest/vueda.user/vueda.user_2fa_reauthenticate_create.md); [ViewReauthenticate](/v3/reference/api/vue/ViewReauthenticate.md); [`vueda.core.reauthentication`](/v3/reference/api/py/vueda.core.reauthentication.md); `ACCOUNT_REAUTHENTICATION_TIMEOUT`
- Described in: [Build Auth Views](/v3/guides/build-auth-views.md#build-a-re-authentication-view)

## Resource

A domain surface implemented across model, serializer, viewset, routing, and client config/UI.

## Route Admission

The client-side checks that a navigation must pass to open one of the [CRUD Routes](/v3/reference/glossary.md#crud-routes), in order: optional sign-in, action allowlist, optional group membership. The allowlist is the user's [Model Actions](/v3/reference/glossary.md#model-actions), narrowed by `routeActions`, plus the user's [permitted transition codes](/v3/reference/glossary.md#permitted-transitions). A failed check redirects or cancels the navigation, and the server still authorizes every request on its own.

- Names: [`makeCRUDRoutes`](/v3/reference/api/js/router/makeCrud/functions/makeCRUDRoutes.md); [`requireAuth`](/v3/reference/api/js/router/guards/functions/requireAuth.md); [`requireModelInfo`](/v3/reference/api/js/router/guards/functions/requireModelInfo.md); [`requireGroups`](/v3/reference/api/js/router/guards/functions/requireGroups.md); [`routeActions`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#routeActions); [`actionRedirect`](/v3/reference/api/js/router/makeCrud/functions/makeCRUDRoutes.md#param-params-actionRedirect)
- Described in: [Routing and View Resolution Model](/v3/core-concepts/routing-and-view-resolution-model.md#route-guard-chain)

## Row Link

A link from one list column's cells to each row's update view, or to its read view when you cannot update the row. You turn it on by naming the column in the model config's `detailLinkField`. The row's [Available Actions](/v3/reference/glossary.md#available-actions) decide which view the link opens, if any.

- Names: [`detailLinkField`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#detailLinkField); [`LinkModelView`](/v3/reference/api/vue/LinkModelView.md)
- Described in: [Link List Rows to Read and Update Views](/v3/guides/link-list-rows-to-detail-views.md)

## Row-Level Hook Surface

The row-level extension points (`check_queryset`, `check_instance`, and workflow variants) where project policy can filter rows or override object decisions.

## Row-Level Permissions

Project rules, declared in a model's inner `RowLevelPermissions` class, that limit which rows a user may act on. `check_queryset` filters `list`, bulk `destroy`, and the history events that a user sees about related rows; `check_instance` joins each object permission check. It is opt-in server enforcement, and [Row-Level Workflow Permissions](/v3/reference/glossary.md#row-level-workflow-permissions) adds two hooks for workflow models.

- Names: `RowLevelPermissions`; [`BaseRowLevelPermissions`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md); [`check_queryset`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_queryset); [`check_instance`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_instance); [`check_queryset_workflow`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_queryset_workflow); [`check_instance_workflow`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_instance_workflow); [`filter_rows_for_user`](/v3/reference/api/py/vueda.core.permissions.md#filter_rows_for_user)
- Described in: [Row-Level Permission Filtering](/v3/core-concepts/row-level-permission-filtering.md#authority-and-boundaries)

## Row-Level Workflow Permissions

The two row-level hooks that run only for a [Workflow-Enabled Model](/v3/reference/glossary.md#workflow-enabled-model). `check_instance_workflow` runs last in an object check and can override any earlier decision, a state deny included. `check_queryset_workflow` can narrow a list further but cannot restore rows that [State Permission](/v3/reference/glossary.md#state-permission) filtering removed.

- Names: [`check_instance_workflow`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_instance_workflow); [`check_queryset_workflow`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_queryset_workflow); [`state_denied_annotation`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_queryset_workflow-param-state_denied_annotation); [`state_granted_annotation`](/v3/reference/api/py/vueda.core.permissions/BaseRowLevelPermissions.md#check_queryset_workflow-param-state_granted_annotation)
- Described in: [Row-Level Permission Filtering](/v3/core-concepts/row-level-permission-filtering.md#queryset-filtering)

## Sent Item

A [Queue Item](/v3/reference/glossary.md#queue-item) in a [Done State](/v3/reference/glossary.md#done-state), served by its own endpoints for delivery history and resend. Resending a sent item creates a new queue item and schedules it.

- Names: [`SentItem`](/v3/reference/api/py/vueda.vdq.models/SentItem.md); [`SentItemManager`](/v3/reference/api/py/vueda.vdq.models/SentItemManager.md); [sent item endpoint](/v3/reference/api/rest/vueda.vdq/vueda.vdq_sentitem_list.md); [resend endpoint](/v3/reference/api/rest/vueda.vdq/vueda.vdq_sentitem_resend_create_2.md); [`DefaultSentItem`](/v3/reference/api/rest/schemas/DefaultSentItem.md)
- Described in: [VDQ and Background Work Model](/v3/core-concepts/vdq-and-background-work.md#done-state-semantics-and-cleanup-gating)
- Upstream: [Django: proxy models](https://docs.djangoproject.com/en/6.1/ref/models/options/#django.db.models.Options.proxy)

## Sent Item (VDQ)

The completed-history view of a VDQ queue record used for sent-item listing and resend operations.

## Serializer-Only Registration

Registering a model with `register_serializer` and no viewset. The model gets field, expand, and permission metadata and its choices endpoints, and no actions, filtering, or column totals.

- Names: [`register_serializer`](/v3/reference/api/py/vueda.info.registration.md#register_serializer)
- Described in: [Canonical Registration and Model Discovery](/v3/core-concepts/canonical-registration-and-discovery.md#viewset-presence-and-metadata-completeness)

## Server Feedback

Validation errors and [Warning Confirmation](/v3/reference/glossary.md#warning-confirmation) warnings from the server, stored in the [Form Context](/v3/reference/glossary.md#form-context) under the reserved `server` code. Local validation cannot write that code. A field's server feedback clears when the field blurs, and remaining server errors do not block the next submit.

- Names: [`ServerFeedbackError`](/v3/reference/api/js/utils/errors/members/ServerFeedbackError.md); [`FormValidationError`](/v3/reference/api/js/utils/errors/members/FormValidationError.md); [`handleServerFormValidationError`](/v3/reference/api/js/use/useForm/types/FormContext.md#handleServerFormValidationError); [`clearServerErrors`](/v3/reference/api/js/use/useForm/types/FormContext.md#clearServerErrors)
- Described in: [Form State and Validation Lifecycle](/v3/core-concepts/form-state-and-validation-lifecycle.md#server-validation-ingestion-and-clearing)

## Skin

The token-level look of VUEDA: color, type, spacing, radius, and density. A re-skin changes these values through [Theme Token](/v3/reference/glossary.md#theme-token) overrides and keeps each component's [Visual Contract](/v3/reference/glossary.md#visual-contract).

- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#brand-css-token-overrides)

## Sparse Fields

A request option that narrows a response to named fields. You list fields to keep in `f` and fields to drop in `om`; on a write, both shape only the response. `f` also requests fields that a response leaves out by default, such as [Available Actions](/v3/reference/glossary.md#available-actions).

- Names: [`FIELDS_PARAM`](/v3/reference/api/js/utils/constants.md#FIELDS_PARAM); [`OMIT_PARAM`](/v3/reference/api/js/utils/constants.md#OMIT_PARAM); [`fetchFields`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#fetchFields)
- Described in: [Field and Expand Semantics](/v3/core-concepts/field-and-expand-semantics.md#parameter-namespace-and-wire-shape)
- Upstream: [drf-flex-fields2: `FlexFieldsSerializerMixin`](https://drf-flex-fields2.readthedocs.io/en/stable/api/rest_flex_fields2/serializers/FlexFieldsSerializerMixin.html#rest_flex_fields2.serializers.FlexFieldsSerializerMixin)

## State Permission

A rule that grants or denies one permission codename to one group while an object is in one workflow state. On an object check, a grant overrides a [Baseline Permission](/v3/reference/glossary.md#baseline-permission) denial and a deny overrides a grant; when rules conflict, deny wins. List filtering applies the same rules to each row; this is server enforcement. Superusers pass before state rules run.

- Names: [`StatePermission`](/v3/reference/api/py/vueda.workflow.models/StatePermission.md); [`check_state_permission`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#check_state_permission)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#state-permission-data-model)
- Upstream: [Django: `Permission`](https://docs.djangoproject.com/en/6.1/ref/contrib/auth/#django.contrib.auth.models.Permission); [Django: `Group`](https://docs.djangoproject.com/en/6.1/ref/contrib/auth/#django.contrib.auth.models.Group)

## Theme Key

One entry in the [Theme Registry](/v3/reference/glossary.md#theme-registry), named after the component it styles (`Button`). A [Composition Primitive](/v3/reference/glossary.md#composition-primitive) key has an underscore prefix (`_ButtonBase`). Each theme key holds one or more [Theme Slot](/v3/reference/glossary.md#theme-slot) entries.

- Names: [theme keys index](/v3/reference/theming/keys.md); example [`Button`](/v3/reference/theming/keys/Button.md); [`ComponentTheme`](/v3/reference/api/js/use/useTheme/types/ComponentTheme.md)
- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#family-meta-keys)

## Theme Override

A partial theme object, keyed by component name, that you pass through a component's `themeOverride` prop. `useThemeOverride` merges it with overrides from ancestors and provides the result to every descendant. It changes one subtree of the page.

- Names: [`themeOverride`](/v3/reference/api/js/use/useTheme.md#THEME_OVERRIDE_PROPS); [`useThemeOverride`](/v3/reference/api/js/use/useTheme/functions/useThemeOverride.md)
- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#instance-usethemeoverride)

## Theme Registry

The active theme: a JavaScript object that maps each component name to its [Theme Key](/v3/reference/glossary.md#theme-key) entry. Each themed component adds its default entry with `patchTheme` when its code loads. `setTheme` replaces those defaults. Your project changes go in through `overrideTheme`, which keeps them in a separate store above the defaults, whatever order the two load in. `clearThemeOverrides` removes them.

- Names: [`patchTheme`](/v3/reference/api/js/use/themeRegistry/functions/patchTheme.md); [`setTheme`](/v3/reference/api/js/use/themeRegistry/functions/setTheme.md); [`overrideTheme`](/v3/reference/api/js/use/themeRegistry/functions/overrideTheme.md); [`clearThemeOverrides`](/v3/reference/api/js/use/themeRegistry/functions/clearThemeOverrides.md); [`getTheme`](/v3/reference/api/js/use/themeRegistry/functions/getTheme.md); [`ThemeObject`](/v3/reference/api/js/use/useTheme/types/ThemeObject.md)
- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#how-the-theme-is-registered)

## Theme Slot

One named element of a [Theme Key](/v3/reference/glossary.md#theme-key), such as `root` or `thumb`, that receives its own classes. Vue slots, which pass template content into a component, are a separate feature.

- Names: example [`_ButtonBase.root`](/v3/reference/theming/keys/_ButtonBase.md#theme-key-_ButtonBase-root); [`useTheme`](/v3/reference/api/js/use/useTheme/functions/useTheme.md)
- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#how-the-layers-interact)

## Theme Token

A CSS custom property defined in the default theme's `base.css`, such as `--primary` or `--vueda-control-height`. Theme classes read their values from tokens. Overriding a token after the `base.css` import changes every component that uses it.

- Names: [theme tokens index](/v3/reference/theming/tokens.md); examples [`--primary`](/v3/reference/theming/tokens/color-palette-light.md#css-token-primary) and [`--vueda-control-height`](/v3/reference/theming/tokens/control-sizing-vueda-canon.md#css-token-vueda-control-height)
- Described in: [Theming and Customization](/v3/core-concepts/theming-and-customization.md#brand-css-token-overrides)

## Tone and Emphasis

The two design axes of a `Button`. Tone is the color role (`neutral`, `primary`, `destructive`); emphasis is the structure (`fill`, `outline`, `ghost`, `link`). Each pair maps to one button [Composition Primitive](/v3/reference/glossary.md#composition-primitive).

- Names: [`tone`](/v3/reference/api/vue/Button.md#prop-tone); [`emphasis`](/v3/reference/api/vue/Button.md#prop-emphasis); [`resolveButtonVariant`](/v3/reference/api/js/controls/button/buttonVariant/functions/resolveButtonVariant.md); [`actionTone`](/v3/reference/api/js/utils/actionVariant/functions/actionTone.md); [`resolveActionVariant`](/v3/reference/api/js/utils/actionVariant/functions/resolveActionVariant.md)
- Described in: [Buttons](/v3/reference/components/buttons.md#choosing-tone-and-emphasis)

## Transition

A workflow operation that moves an object from one of its source states to a target state. Its `code` identifies it in API requests and client routes, and its `name` is display text.

- Names: [`Transition`](/v3/reference/api/py/vueda.workflow.models/Transition.md); [`Transition` schema](/v3/reference/api/rest/schemas/Transition.md); [`PATCH execute-transition/{object_id}/`](/v3/reference/api/rest/vueda.workflow/vueda.workflow_workflows_execute_object_transition_partial_update.md); [`executeTransition`](/v3/reference/api/js/stores/storeWorkflow/methods/executeTransition.md); `transition_code`
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#transition-permission-gates)

## Transition Permission

A row that names one permission a user must hold to execute one transition. The user must hold every permission that the rows name, checked against the object so that [State Permission](/v3/reference/glossary.md#state-permission) rules apply. A transition with no rows denies every user, superusers included; this is server enforcement.

- Names: [`TransitionPermission`](/v3/reference/api/py/vueda.workflow.models/TransitionPermission.md); [`check_transition_permission`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#check_transition_permission)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#transition-permission-gates)
- Upstream: [Django: `PermissionsMixin.has_perms`](https://docs.djangoproject.com/en/6.1/topics/auth/customizing/#django.contrib.auth.models.PermissionsMixin.has_perms)

## Two-Factor Authentication

A second sign-in step that asks for a one-time code from an authenticator app, SMS, or email. VUEDA stores each method a user registers as a `TOTPDevice`. The server requires the code; the client routes to the `2fa` page when the server asks for it.

- Names: [`TOTPDevice`](/v3/reference/api/py/vueda.user.models/TOTPDevice.md); [`storeUser.twoFactorAuthenticate`](/v3/reference/api/js/stores/storeUser/methods/twoFactorAuthenticate.md); [2FA endpoint](/v3/reference/api/rest/vueda.user/vueda.user_2fa_authenticate_create.md); `TWO_FACTOR_AUTHENTICATION_OPTIONS`
- Described in: [Build Auth Views](/v3/guides/build-auth-views.md#route-two-factor-sign-in)

## Valid Transitions

The `valid_transitions` field on a workflow model's object payload: the transitions from the object's current state that pass the [Workflow Permission](/v3/reference/glossary.md#workflow-permission) and [Transition Permission](/v3/reference/glossary.md#transition-permission) gates for that object. A source state marked ignored contributes no transitions. The field is empty when the user fails the workflow gate. The detail view reads it for its transition buttons.

- Names: `valid_transitions`; [`AvailableTransitionField`](/v3/reference/api/py/vueda.workflow.fields/AvailableTransitionField.md); [`available_transitions`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#available_transitions)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#which-gate-each-workflow-endpoint-applies)

## VDQ (VUEDA Dispatch Queue)

VUEDA's Django app for queued outbound email and SMS. Each message to one receiver is a [Queue Item](/v3/reference/glossary.md#queue-item) with a workflow state. Celery workers send it, and provider callbacks or SMS polling record the delivery result.

- Names: [`vueda.vdq`](/v3/reference/api/py/vueda.vdq.md)
- Described in: [VDQ and Background Work Model](/v3/core-concepts/vdq-and-background-work.md)
- Upstream: [Celery: `Celery`](https://docs.celeryq.dev/en/v5.6.3/reference/celery.html#celery.Celery)

## View Field Lists

The three field lists a [Model Config](/v3/reference/glossary.md#model-config) holds for each view. `displayFields` is what the view shows, `fetchFields` what it requests in `f`, and `submitFields` what a save sends. [Model Info](/v3/reference/glossary.md#model-info) supplies their defaults.

- Names: [`displayFields`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#displayFields); [`fetchFields`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#fetchFields); [`submitFields`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#submitFields)
- Described in: [Configure `list`/`read`/`create`/`update` Views](/v3/guides/configure-crud-views.md#choose-each-view-s-field-lists)

## Visual Contract

What a component page guarantees stays true after a re-skin: the component's variants, sizes, and states. Each page links the theme keys and theme tokens that set its current values.

- Described in: [Components](/v3/reference/components/index.md)

## VUEDA Model

A Django model that derives from `FormattedNameBaseModel`, usually through VUEDA's abstract model bases `VuedaModel` and `Lookup`. Only a VUEDA model carries a [Formatted Name](/v3/reference/glossary.md#formatted-name) and a [Feature Policy](/v3/reference/glossary.md#feature-policy).

- Names: [`VuedaModel`](/v3/reference/api/py/vueda.core.models/VuedaModel.md); [`Lookup`](/v3/reference/api/py/vueda.core.models/Lookup.md); [`FormattedNameBaseModel`](/v3/reference/api/py/vueda.core.models/FormattedNameBaseModel.md); [`supports_vueda_feature_policy`](/v3/reference/api/py/vueda.core.models.md#supports_vueda_feature_policy)
- Described in: [Model Feature Policy](/v3/core-concepts/model-feature-policy.md#which-models-carry-policy)
- Upstream: [Django: `Model`](https://docs.djangoproject.com/en/6.1/ref/models/instances/#django.db.models.Model)

## Warning Channel

The confirmation-gated path for advisory server warnings: a non-empty `get_warnings()` result withholds the write and returns `409 Conflict` until the client resubmits with an acknowledged digest.

## Warning Confirmation

The step that holds a write until the user confirms its advisory warnings. The server answers an unacknowledged write with `409 Conflict`, the warnings, and a digest. The client resubmits with that digest in the `Acknowledge-Warnings` header.

- Names: [`gate_warnings`](/v3/reference/api/py/vueda.core.exceptions.md#gate_warnings); [`ConfirmationRequired`](/v3/reference/api/py/vueda.core.exceptions/ConfirmationRequired.md); [`ACKNOWLEDGE_WARNINGS_HEADER`](/v3/reference/api/py/vueda.core.exceptions.md#ACKNOWLEDGE_WARNINGS_HEADER); [`WarningConfirmationMixin`](/v3/reference/api/py/vueda.core.viewsets/WarningConfirmationMixin.md); [`ConfirmationRequiredError`](/v3/reference/api/js/utils/errors/members/ConfirmationRequiredError.md)
- Described in: [Error and Validation Contract](/v3/core-concepts/error-and-validation-contract.md#warning-confirmation-semantics)

## Widget

The input control inside a [Form Field](/v3/reference/glossary.md#form-field), such as a text box or a select. VUEDA picks it from the form's `widgetComponents` prop, then the model config's `widgetComponents`, then the default type mapping, which `mergeDefaultFieldMappings` extends. A field that renders read-only uses its type's read-only widget and ignores those overrides. When the type has no read-only widget, the field uses `WidgetReadOnly`.

- Names: [`useWidget`](/v3/reference/api/js/use/useWidget/functions/useWidget.md); [`widgetComponents` prop](/v3/reference/api/vue/FormModel.md#prop-widgetComponents); [`ModelConfig.widgetComponents`](/v3/reference/api/js/stores/storeModelConfig/types/ModelConfig.md#widgetComponents); [`defaultFieldMappings`](/v3/reference/api/js/utils/fieldMappings.md#defaultFieldMappings); [`mergeDefaultFieldMappings`](/v3/reference/api/js/utils/fieldMappings/functions/mergeDefaultFieldMappings.md); [`WidgetReadOnly`](/v3/reference/api/vue/WidgetReadOnly.md); [`WIDGET_PROPS`](/v3/reference/api/js/use/useWidget.md#WIDGET_PROPS); [`availableWidgets`](/v3/reference/api/js/utils/formLookups.md#availableWidgets)
- Described in: [Contract-First Dynamic UI](/v3/core-concepts/contract-first-dynamic-ui.md#field-and-widget-resolution)

## Wire Query Parameters

The short query parameter names that VUEDA endpoints read. `f`, `e`, and `om` shape the fields; `s` searches; `o` orders; `p` and `ps` paginate; `ct` requests column totals. Server settings define the names, and the client holds matching constants.

- Names: [`FIELDS_PARAM`](/v3/reference/api/js/utils/constants.md#FIELDS_PARAM); [`EXPAND_PARAM`](/v3/reference/api/js/utils/constants.md#EXPAND_PARAM); [`OMIT_PARAM`](/v3/reference/api/js/utils/constants.md#OMIT_PARAM); [`SEARCH_PARAM`](/v3/reference/api/js/utils/constants.md#SEARCH_PARAM); [`ORDERING_PARAM`](/v3/reference/api/js/utils/constants.md#ORDERING_PARAM); [`PAGE_PARAM`](/v3/reference/api/js/utils/constants.md#PAGE_PARAM); [`PAGE_SIZE_PARAM`](/v3/reference/api/js/utils/constants.md#PAGE_SIZE_PARAM); [`COLUMN_TOTALS_PARAM`](/v3/reference/api/js/utils/constants.md#COLUMN_TOTALS_PARAM)
- Described in: [Configuration Surface and Defaults](/v3/core-concepts/configuration-surface-and-defaults.md#wire-query-parameter-namespace)
- Upstream: [DRF: `SearchFilter`](https://www.django-rest-framework.org/api-guide/filtering/#searchfilter); [DRF: `OrderingFilter`](https://www.django-rest-framework.org/api-guide/filtering/#orderingfilter)

## Workflow

The states, transitions, initial state, and permission rows defined for one model's [Content Type](/v3/reference/glossary.md#content-type); each model has at most one. You build workflows in the workflow management views and ship them to other environments as [Workflow Migration](/v3/reference/glossary.md#workflow-migration) files.

- Names: [`Workflow`](/v3/reference/api/py/vueda.workflow.models/Workflow.md); [`State`](/v3/reference/api/py/vueda.workflow.models/State.md); [`InitialState`](/v3/reference/api/py/vueda.workflow.models/InitialState.md)
- Described in: [Manage Workflows and Generate Workflow Migrations](/v3/guides/manage-workflows.md#workflow-management-ui)

## Workflow Migration

A Django migration that `makeworkflowmigrations` writes from the workflow changes recorded in history, so a workflow built in one database reaches other environments. It names records by code, app label, and model, since primary keys differ between databases.

- Names: [`makeworkflowmigrations`](/v3/reference/api/py/vueda.workflow.management.commands.makeworkflowmigrations/Command.md); [`updateworkflowmigrations`](/v3/reference/api/py/vueda.workflow.management.commands.updateworkflowmigrations/Command.md)
- Described in: [Manage Workflows and Generate Workflow Migrations](/v3/guides/manage-workflows.md#generating-workflow-migrations)
- Upstream: [Django: `RunPython`](https://docs.djangoproject.com/en/6.1/ref/migration-operations/#django.db.migrations.operations.RunPython)

## Workflow Overlay

The effect of [State Permission](/v3/reference/glossary.md#state-permission) rules on a [Workflow-Enabled Model](/v3/reference/glossary.md#workflow-enabled-model). Object checks and list filtering grant or deny [CRUD](/v3/reference/glossary.md#crud) codenames by the object's workflow state. This is server enforcement.

- Names: [`StatePermission`](/v3/reference/api/py/vueda.workflow.models/StatePermission.md); [`filter_rows_for_user`](/v3/reference/api/py/vueda.core.permissions.md#filter_rows_for_user)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#overlay-boundary-and-authority)

## Workflow Permission

A row that names one permission a user must hold to use a workflow's transitions. The user must hold every permission that the rows name, and a workflow with no rows denies every user, superusers included. Groups receive these permissions as ordinary Django group permissions; this is server enforcement.

- Names: [`WorkflowPermission`](/v3/reference/api/py/vueda.workflow.models/WorkflowPermission.md); [`check_workflow_permission`](/v3/reference/api/py/vueda.workflow.models/WorkflowModelMethods.md#check_workflow_permission)
- Described in: [Workflow as a Permission Overlay](/v3/core-concepts/workflow-permission-overlay.md#transition-permission-gates)
- Upstream: [Django: `PermissionsMixin.has_perms`](https://docs.djangoproject.com/en/6.1/topics/auth/customizing/#django.contrib.auth.models.PermissionsMixin.has_perms)

## Workflow-Enabled Model

A [VUEDA Model](/v3/reference/glossary.md#vueda-model) whose [Feature Policy](/v3/reference/glossary.md#feature-policy) enables workflow, with `enabled = True` in `class Vueda.Workflow`. It needs a [Workflow](/v3/reference/glossary.md#workflow) definition. Without one, saving an object and every workflow request raise `WorkflowNotConfiguredError`, which the API returns as HTTP 500.

- Names: `class Vueda.Workflow`; [`workflow_enabled`](/v3/reference/api/py/vueda.core.installed_apps.md#workflow_enabled); [`workflow_enabled` (model info)](/v3/reference/api/py/vueda.info.serializers/ModelInfoSerializer.md#workflow_enabled); [`WorkflowNotConfiguredError`](/v3/reference/api/py/vueda.workflow.exceptions/WorkflowNotConfiguredError.md)
- Described in: [Model Feature Policy](/v3/core-concepts/model-feature-policy.md#history-and-workflow)