Permissions reference

Every permission Fabrik recognises — the Django model permissions enforced on each resource, the custom bypass permission, and the GroupQuota feature toggles — with what each one actually allows.

When you build a custom group, you're combining two independent systems:

Django model permissions — fine-grained view / add / change / delete rights on each resource type, enforced on Fabrik's CRUD APIs.
GroupQuota feature toggles — coarse on/off switches that gate whole features (AWX, Time Machine, AI builder, export, sharing).

This page lists every permission in both systems and what each one means in practice. For how groups stack and how quotas combine, see Groups and quotas.

Two shortcuts bypass all of this: a superuser and any member of the Admin group skip the permission system entirely and can do everything. Everything below applies to non-admin groups.

How model permissions are enforced

Fabrik's CRUD endpoints use a permission class (FabrikModelPermissions) that maps the HTTP method to a Django permission on the resource's model. The four verbs always mean the same thing:

Permission verb	Codename	Gates	In the UI
View	`view_<model>`	`GET` / `HEAD`	Seeing the resource in lists and detail panels
Add	`add_<model>`	`POST`	Creating a new one
Change	`change_<model>`	`PUT` / `PATCH`	Editing an existing one
Delete	`delete_<model>`	`DELETE`	Removing one

Permission codenames are <app_label>.<verb>_<model> — e.g. queries.view_savedquery, awx.add_automationtemplate.

View is required to do anything. Unlike stock Django REST Framework (which leaves read methods open), Fabrik requires view_<model> for GET. A group with add_savedquery but not view_savedquery can't use saved queries at all — grant view_ alongside any write verb.

Not every resource is governed by model permissions. The CRUD verbs apply to the areas in the tables below. Time Machine, the MIM browser, notifications, and the dashboard are gated differently — by feature toggles and per-user ownership rather than per-model CRUD rights (see Beyond model permissions).

Queries (`queries.*`)

The core query-building surface. This is where most custom-group tuning happens.

Model	What `view` / `add` / `change` / `delete` control
`savedquery`	Saved queries — the canvas graphs users build, run, and share. The central resource; most groups need at least `view` + `add` + `change`.
`category`	Folders that organise saved queries.
`scheduledtask`	Scheduled/recurring task definitions. `add`/`change` let a user create and edit schedules.
`scheduledtaskexecution`	Run records produced by scheduled tasks. Read-oriented — `view` to see run history; rows are created by the system, not by hand.
`queryexecutionlog`	History of query executions. Effectively read-only (`view`).
`chainexecutionjob`	Pipeline (multi-stage query) runs. `view` to monitor; created by the run engine.
`chainiterationresult`	Per-stage results inside a pipeline run. Internal detail — rarely assigned directly.
`taskmanagementsettings`	Global task-management defaults (retries, log retention, email). Admin-level; `change` to edit.
`aiquerybuildersettings`	Platform AI-builder settings. Admin-level.
`useraiprovider`	A user's own AI provider/key config (BYOK). Normally self-managed per user.

APIC connections (`apic_connections.*`)

Model	What the verbs control
`apicconnection`	Saved APIC controller credentials. `add`/`change` is admin-only in practice (creating connections is restricted); `view` lets a user pick connections shared with them.

AWX automation (`awx.*`)

Model	What `view` / `add` / `change` / `delete` control
`awxconnection`	Saved AWX/Tower connections.
`templatecategory`	Categories for organising automation templates.
`automationtemplate`	Templates that turn query results into playbook runs (schema, validation, execution mode).
`automationrequest`	A user's request to run a template against rows. `add` = submit a request.
`automationexecution`	The launched AWX job records. Read-oriented (`view`); created when a request executes.
`columntemplate`	Reusable column definitions for template schemas.
`validationlist`	Named allowed-value lists used in validation.
`regexpattern`	Named regex patterns used in validation.
`validationusage`	Usage-tracking rows for validation. Internal — rarely assigned.
`joboutputchunk`	Streamed job-output fragments. Internal storage; `view` is implied by execution access.

Custom permission: `awx.bypass_validation`

The only non-CRUD permission in Fabrik. It's defined on the template model:

awx.bypass_validation — "Can bypass validation for templates." Combined with a template's allow_validation_bypass flag, a holder can submit a request whose validation produced warnings without being blocked. Validation still runs and is recorded; it just stops blocking. Grant it deliberately — it's a break-glass for incident response. See Validations → Bypass.

Time Machine (`time_machine.*`)

Model	Notes
`queryexecutionsnapshot`	Captured query results. Not gated by these model perms in the UI — Time Machine access is governed by the `can_use_time_machine` toggle and snapshot ownership/visibility. The perms exist for admin/API completeness.
`timemachinesettings`	Per-user retention settings. Self-managed.

Notifications (`notifications.*`)

Notifications are per-user and owned, so day-to-day access doesn't depend on these model perms — a user always sees and manages their own. The perms matter mainly for admin tooling.

Model	Notes
`notification`	A delivered notification. Users manage their own.
`notificationpreference`	Per-user delivery preferences (server-side).
`notificationbuffer`	Holds pending notifications during a digest window. Internal.
`escalationrule`	Escalation rules — created and managed in the Django admin, not via a Fabrik group permission.

Audit (`audit.*`)

Model	Notes
`auditlog`	The immutable audit trail. Read-only — written only by the backend; `view` is the only meaningful verb, and it's admin-gated.
`auditlogsettings`	Audit retention/config. Admin-level.
`loginattempt`	Login-attempt records (security). Read-only, admin-gated.

Users and groups (`users.` / `auth.`)

Model	What the verbs control
`auth.group`	Groups themselves. `add`/`change`/`delete` = manage groups (admin territory).
`auth.permission`	The permission catalogue. Read-only listing for permission pickers.
`users.groupquota`	The quota/feature-toggle row attached to a group. `change` = edit a group's limits.
`users.userprofile`	Extended user profile data. Self-managed for one's own profile; admin for others via user management.
`users.passwordresetcode`	Password-reset codes. Internal — never assigned to groups.

User management actions (reset password, activate/deactivate, grant/revoke permissions, etc.) live under the admin-only User Management surface, not under per-model verbs for regular groups. See Users.

MIM (`mim.*`)

The MIM browser is open to any authenticated user — browsing classes isn't gated by these model perms. The models here back per-user conveniences:

Model	Notes
`favoriteclass`	A user's favourited classes. Self-managed.
`recentclass`	Recently-viewed classes. Self-managed.
`tabletemplate`	Saved table-column layouts.
`usertablepreference`	Per-user table display preferences.

MIM installation/management (mim_registry.* — devnetversion, mimversion, mimimportrun, mimimportjob, mimregistryconfig) is admin-only and not something you assign to a custom group.

Feature toggles (GroupQuota)

Separate from Django permissions, every group's GroupQuota carries eight boolean feature toggles. These gate whole features at the UI and API level. A toggle that's off removes the feature even if the user holds the matching model permissions — toggles are checked before the numeric quota and the model perms.

Toggle	Default	What turning it off does
`can_create_queries`	on	Removes the ability to create/save new queries (can still run existing ones if `can_execute_queries`).
`can_execute_queries`	on	Blocks running queries against APIC.
`can_create_scheduled`	on	Blocks creating scheduled tasks.
`can_use_awx`	on	Hides and blocks the entire AWX/Ansible automation surface.
`can_use_time_machine`	on	Hides and blocks Time Machine (snapshots, compare, drift).
`can_export_data`	on	Blocks CSV/Excel/JSON export of results.
`can_share_resources`	on	Blocks sharing queries/resources with others or making them public.
`can_use_ai_builder`	on	Hides and blocks the AI query builder.

Toggles short-circuit. If can_use_awx=false, a user never reaches the AWX model permissions or the max_awx_requests_daily quota — the feature is simply gone for them. Don't bother granting AWX model perms to a group whose toggle is off.

When two groups disagree on a toggle, the more permissive value wins (any true grants it) — consistent with how numeric quotas combine. See Groups and quotas → How limits combine.

Beyond model permissions

A few areas are intentionally not governed by per-model CRUD permissions, so granting or withholding those perms has no visible effect:

Time Machine — gated by can_use_time_machine + snapshot ownership/visibility.
MIM browser — open to any authenticated user.
Notifications — per-user; you always manage your own.
Dashboard — visible to any authenticated user.
Escalation rules — Django admin only.
MIM installation and audit log — admin only.

For these, reach for the feature toggle (Time Machine, export, etc.) or admin/superuser status rather than model permissions.

Building a custom group — practical recipes

A few starting points; tune from the closest built-in role template.

Read-only analyst

Perms: view_* across queries, awx, apic_connections.
Toggles: can_execute_queries=on, everything else off.
Effect: can browse and run existing queries, see results, but create nothing and use no automation.

Query author, no automation

Perms: view_* plus add_/change_savedquery, add_/change_category.
Toggles: can_create_queries=on, can_execute_queries=on, can_use_time_machine=on; can_use_awx=off, can_use_ai_builder to taste.
Effect: full query authoring and history, no AWX surface.

Automation operator, no deletes

Perms: view_*, add_/change_savedquery, add_/change_scheduledtask, add_automationrequest.
Toggles: AWX on, export on.
Withhold all delete_* so the operator can't remove shared resources.

Contractor (bounded)

Start from Editor, set can_use_awx=false, can_share_resources=false, and tight daily limits (query_execution_daily, max_export_rows).
Keeps third-party access read/build-only and non-destructive.

Grant view_ generously, write verbs narrowly, and delete_ rarely. Most "why can't this user see anything?" tickets are a missing view_ permission next to a granted write verb.

Permissions reference

On this page