Role

Mapuj użytkowników i grupy na role i ustalaj, co każda rola może robić.

Atrybut roles
Rola default
Obiekt Role
Opcje ról

Atrybut roles

Lista roles najwyższego poziomu w config.yaml:

Atrybut Komentarze

Atrybut	Komentarze
roles array	Roles 🔗 valid role object The roles provide RBAC. Each role has a name and 1 or more groups (local, ldap or entraid). The `admin` and `default` roles are mandatory (`public` is the old name of `default`, and still works). Since version 4.0.11 you can also add users (local, ldap or entraid). Since version 5.0.8 options are introduced to add specific role-options. showDesigner: The user can see the designer allowFormDesign: The user can edit the forms config in the designer (categories, constants, forms: save, restore, pull and push the forms repositories). Without it the designer shows them read-only. Default true. (Added in 7.3.0) designAllForms: The designer shows and edits every form. Without it, only the forms whose `roles` hold one of the user’s roles: the others are left out (never named, a name taken by one is only said to be taken, a form of theirs naming one as a subform shows nothing of it). The subforms no hidden form uses (new ones included) are theirs to edit, a subform a hidden form uses as well as one of theirs is shown read only, and a form saved (a subform aside) must keep one of their roles. A file holding several forms keeps the hidden ones as they are, restoring a backup needs this option, and the form files are left out of the designer’s other explorers (a repository’s whole tree, as the workflows show it). The forms list leaves out the warning of a form name defined twice unless both copies are theirs, and the settings pages’ Forms tabs and a credential’s Used by tab, reached with a part of the settings only (not showSettings), list only the forms their designer shows. Limits the forms only (playbooks and workflows have designAllPlaybooks and designAllWorkflows); inventories, vars files, categories and constants stay visible to every designer. Off, the user may not run a raw expression either (POST /api/v2/expression with an `expression` of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0) allowPlaybookDesign: The user can edit the playbooks in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.0.0) designAllPlaybooks: Show and edit every playbook in the designer; without it, only the playbooks used by the forms the user can see, and the ones no form uses yet. A form uses a playbook by its `playbook` (with `playbookSubPath`), its ansible steps and the job template nodes of the workflows it runs (on the app or an rte runner); the forms it can see follow designAllForms. A hidden playbook is never listed nor read: it answers as a missing file, or as a file there already, and a form of theirs naming one, or a workflow file whose nodes run one, is refused. Edit Playbooks still decides whether the shown ones can be changed. Off, the user may not run a raw expression either (POST /api/v2/expression with an `expression` of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0) allowWorkflowDesign: The user can edit the workflows in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0) designAllWorkflows: Show and edit every workflow in the designer; without it, only the workflows used by the forms the user can see, and the ones no form uses yet. A form uses the workflow file it runs (`workflow`) and the nested workflows that one runs (every workflow a reference may mean, when several have its name); the forms it can see follow designAllForms. A hidden workflow file is never listed nor read (nor named in a credential’s Used by tab, without showSettings): it answers as a missing file, or as a file there already, and a form of theirs naming one, or a workflow file whose nodes run one, is refused. Edit Workflows still decides whether the shown ones can be changed. Off, the user may not run a raw expression either (POST /api/v2/expression with an `expression` of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0) allowInventoryDesign: The user can edit the inventories in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0) allowVarsFileDesign: The user can edit the vars files in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0) showSettings: The user can see the settings page showDebugButtons: The user can see the debug buttons on a form showExtravars: The user can see the extravars on a form showLogs: The user can see the server log (Settings > Server log) showAuditLog: The user can see the audit log (Settings > Audit log) without the other settings. Default: admins. (Added in 7.3.0) showAppearanceSettings: The user can change Settings > Appearance (defaults, name, logo, icon, links, environment label, announcements) without the other settings. Default false. (Added in 7.3.0) showConnectionsSettings: The user can manage Settings > Connections (repositories, credentials, secret stores, runners, SSH, notifications, chat assistant, MCP, syslog) without the other settings. Default false. (Added in 7.3.0) showJobs: The user can see the jobs page. Default true. showArtifacts: The user can see the artifacts an AWX job returns. Default true. allowFileUploads: The user can upload files through a form’s file fields. Without it the field is read-only and the upload is refused. Default true. (Added in 7.3.0) allowApiTokens: The user can make API tokens (Profile > API token), living up to API_TOKEN_MAX_DAYS. Default false (true for a role that only sets extendedTokenExpiration, as before this option). (Added in 7.3.0) extendedTokenExpiration: With allowApiTokens, the user can also make API tokens that never expire. Default false. showAllJobLogs: The user can see all job logs (not only his own) (Added in 5.0.9) admin: The role’s users are admins, as the admin role’s own: every form, the designer, the settings and the users, whatever the role is called (platformAdmins, infra_admins). Only an admin turns it on for a role with members or adds members to such a role, and a save that would take admin away from the admin saving it is refused. Never on the default role. Default false ; always true for the admin role. (Added in 7.6.0) allowLogin: The user can login. allowBackupOps: The user can perform database operations, such as backup and restore. allowVerboseMode: The user can enable verbose mode on ansible forms. allowJobRelaunch: The user can relaunch jobs with pre-filled form data from previous submissions. allowJobDeletion: The user can delete jobs (their own ; an admin every job). Without it the job history stays whole. Default true. (Added in 7.3.0) manageAllJobs: The user can abort, delete and relaunch the jobs of every user, not only their own, without the admin role (delete and relaunch also need allowJobDeletion and allowJobRelaunch). Default: admins. (Added in 7.3.0) allowScheduledJobs: The user can create and manage scheduled jobs (recurring cron or one-time). Default for admins only. Grant it only to roles you would trust as admins: every user with this option sees and can change all schedules, not only their own, and a schedule they create runs with admin rights, for any form. (Added in 6.1.5) allowStoredJobs: The user can store and load job data for later use. (Added in 6.1.5) allowStoredJobsShare: The user can share a stored job, so other users can load it from the form (they need allowStoredJobsViewAll). The stored job stays theirs: only they (and the admins) can change or delete it. Default: admins. (Added in 7.5.0) allowStoredJobsViewAll: The user sees the stored jobs other users shared, in the Load list of a form they may open, and can load them. Default: admins. (Added in 7.5.0) allowPlannedJobs: The user can plan a one-time run of a form they may run (“Run later”). The job runs as that user, not as admin, and they cannot see or change other schedules. (Added in 6.1.5) allowChat: The user can use the chat assistant (when it is enabled). Default true. (Added in 6.5.0) allowMcp: The user can use the MCP server from an AI agent (when it is enabled). Defaults to the role’s allowChat. (Added in 7.0.0) When options are not set, the admin role will have all options. When options are set on the default role, they are everyone’s defaults: they have the lowest precedence and only fill the options none of the user’s own roles set. You can add options on role level, which override the default role’s options. Between a user’s own roles the most restrictive wins (an option false on one of them is false). The `default` role is every signed-in user’s ; there is no anonymous access. `public` is its name before 7 and keeps working (forms listing `public` still match), but new configs say `default`. The `allowLogin` option is different, that is for the backend. By default everyone can login. You can set it to false on default and then enable on the roles you want to give access. Watch out you don’t lock yourself out. Przykłady: 1) Roles roles: - name: admin # is mandatory groups: - local/admins - ldap/Domain Admins - entraid/Domain Admins - name: operator groups: - local/operator - name: architect groups: - local/architect options: showDesigner: true # architects can see the designer showLogs: true # architects can see the logs allowJobRelaunch: true # architects can relaunch jobs with pre-filled data - name: demo groups: - local/demo - name: usersonly users: - local/myuser - name: default # is mandatory groups: [] options: showDebugButtons: true # everyone can see the debug buttons showExtraVars: true # everyone can see the extravars

roles
array

The roles provide RBAC. Each role has a name and 1 or more groups (local, ldap or entraid). The admin and default roles are mandatory (public is the old name of default, and still works).
Since version 4.0.11 you can also add users (local, ldap or entraid).
Since version 5.0.8 options are introduced to add specific role-options.

showDesigner: The user can see the designer
allowFormDesign: The user can edit the forms config in the designer (categories, constants, forms: save, restore, pull and push the forms repositories). Without it the designer shows them read-only. Default true. (Added in 7.3.0)
designAllForms: The designer shows and edits every form. Without it, only the forms whose roles hold one of the user’s roles: the others are left out (never named, a name taken by one is only said to be taken, a form of theirs naming one as a subform shows nothing of it). The subforms no hidden form uses (new ones included) are theirs to edit, a subform a hidden form uses as well as one of theirs is shown read only, and a form saved (a subform aside) must keep one of their roles. A file holding several forms keeps the hidden ones as they are, restoring a backup needs this option, and the form files are left out of the designer’s other explorers (a repository’s whole tree, as the workflows show it). The forms list leaves out the warning of a form name defined twice unless both copies are theirs, and the settings pages’ Forms tabs and a credential’s Used by tab, reached with a part of the settings only (not showSettings), list only the forms their designer shows. Limits the forms only (playbooks and workflows have designAllPlaybooks and designAllWorkflows); inventories, vars files, categories and constants stay visible to every designer. Off, the user may not run a raw expression either (POST /api/v2/expression with an expression of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0)
allowPlaybookDesign: The user can edit the playbooks in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.0.0)
designAllPlaybooks: Show and edit every playbook in the designer; without it, only the playbooks used by the forms the user can see, and the ones no form uses yet. A form uses a playbook by its playbook (with playbookSubPath), its ansible steps and the job template nodes of the workflows it runs (on the app or an rte runner); the forms it can see follow designAllForms. A hidden playbook is never listed nor read: it answers as a missing file, or as a file there already, and a form of theirs naming one, or a workflow file whose nodes run one, is refused. Edit Playbooks still decides whether the shown ones can be changed. Off, the user may not run a raw expression either (POST /api/v2/expression with an expression of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0)
allowWorkflowDesign: The user can edit the workflows in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0)
designAllWorkflows: Show and edit every workflow in the designer; without it, only the workflows used by the forms the user can see, and the ones no form uses yet. A form uses the workflow file it runs (workflow) and the nested workflows that one runs (every workflow a reference may mean, when several have its name); the forms it can see follow designAllForms. A hidden workflow file is never listed nor read (nor named in a credential’s Used by tab, without showSettings): it answers as a missing file, or as a file there already, and a form of theirs naming one, or a workflow file whose nodes run one, is refused. Edit Workflows still decides whether the shown ones can be changed. Off, the user may not run a raw expression either (POST /api/v2/expression with an expression of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0)
allowInventoryDesign: The user can edit the inventories in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0)
allowVarsFileDesign: The user can edit the vars files in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0)
showSettings: The user can see the settings page
showDebugButtons: The user can see the debug buttons on a form
showExtravars: The user can see the extravars on a form
showLogs: The user can see the server log (Settings > Server log)
showAuditLog: The user can see the audit log (Settings > Audit log) without the other settings. Default: admins. (Added in 7.3.0)
showAppearanceSettings: The user can change Settings > Appearance (defaults, name, logo, icon, links, environment label, announcements) without the other settings. Default false. (Added in 7.3.0)
showConnectionsSettings: The user can manage Settings > Connections (repositories, credentials, secret stores, runners, SSH, notifications, chat assistant, MCP, syslog) without the other settings. Default false. (Added in 7.3.0)
showJobs: The user can see the jobs page. Default true.
showArtifacts: The user can see the artifacts an AWX job returns. Default true.
allowFileUploads: The user can upload files through a form’s file fields. Without it the field is read-only and the upload is refused. Default true. (Added in 7.3.0)
allowApiTokens: The user can make API tokens (Profile > API token), living up to API_TOKEN_MAX_DAYS. Default false (true for a role that only sets extendedTokenExpiration, as before this option). (Added in 7.3.0)
extendedTokenExpiration: With allowApiTokens, the user can also make API tokens that never expire. Default false.
showAllJobLogs: The user can see all job logs (not only his own) (Added in 5.0.9)
admin: The role’s users are admins, as the admin role’s own: every form, the designer, the settings and the users, whatever the role is called (platformAdmins, infra_admins). Only an admin turns it on for a role with members or adds members to such a role, and a save that would take admin away from the admin saving it is refused. Never on the default role. Default false ; always true for the admin role. (Added in 7.6.0)
allowLogin: The user can login.
allowBackupOps: The user can perform database operations, such as backup and restore.
allowVerboseMode: The user can enable verbose mode on ansible forms.
allowJobRelaunch: The user can relaunch jobs with pre-filled form data from previous submissions.
allowJobDeletion: The user can delete jobs (their own ; an admin every job). Without it the job history stays whole. Default true. (Added in 7.3.0)
manageAllJobs: The user can abort, delete and relaunch the jobs of every user, not only their own, without the admin role (delete and relaunch also need allowJobDeletion and allowJobRelaunch). Default: admins. (Added in 7.3.0)
allowScheduledJobs: The user can create and manage scheduled jobs (recurring cron or one-time). Default for admins only. Grant it only to roles you would trust as admins: every user with this option sees and can change all schedules, not only their own, and a schedule they create runs with admin rights, for any form. (Added in 6.1.5)
allowStoredJobs: The user can store and load job data for later use. (Added in 6.1.5)
allowStoredJobsShare: The user can share a stored job, so other users can load it from the form (they need allowStoredJobsViewAll). The stored job stays theirs: only they (and the admins) can change or delete it. Default: admins. (Added in 7.5.0)
allowStoredJobsViewAll: The user sees the stored jobs other users shared, in the Load list of a form they may open, and can load them. Default: admins. (Added in 7.5.0)
allowPlannedJobs: The user can plan a one-time run of a form they may run (“Run later”). The job runs as that user, not as admin, and they cannot see or change other schedules. (Added in 6.1.5)
allowChat: The user can use the chat assistant (when it is enabled). Default true. (Added in 6.5.0)
allowMcp: The user can use the MCP server from an AI agent (when it is enabled). Defaults to the role’s allowChat. (Added in 7.0.0)

When options are not set, the admin role will have all options.
When options are set on the default role, they are everyone’s defaults: they have the lowest precedence and only fill the options none of the user’s own roles set.
You can add options on role level, which override the default role’s options. Between a user’s own roles the most restrictive wins (an option false on one of them is false).
The default role is every signed-in user’s ; there is no anonymous access. public is its name before 7 and keeps working (forms listing public still match), but new configs say default.

The allowLogin option is different, that is for the backend. By default everyone can login.
You can set it to false on default and then enable on the roles you want to give access. Watch out you don’t lock yourself out.

Przykłady:

1) Roles

roles:
- name: admin        # is mandatory
  groups:
  - local/admins
  - ldap/Domain Admins
  - entraid/Domain Admins
- name: operator
  groups:
  - local/operator
- name: architect
  groups:
  - local/architect
  options:
    showDesigner: true      # architects can see the designer
    showLogs: true          # architects can see the logs
    allowJobRelaunch: true  # architects can relaunch jobs with pre-filled data
- name: demo
  groups:
  - local/demo
- name: usersonly
  users:
  - local/myuser
- name: default        # is mandatory
  groups: []  
  options:
    showDebugButtons: true  # everyone can see the debug buttons
    showExtraVars: true     # everyone can see the extravars

Rola default

Każdy zalogowany użytkownik ma rolę default, więc formularz z roles: [default] jest dostępny dla każdego, kto może się zalogować. Nie ma dostępu anonimowego: nikt nie dostaje tej roli bez zalogowania.

Rola nie zawiera grup ani użytkowników, bo i tak obowiązuje wszystkich. Jej options są wartościami domyślnymi dla wszystkich, jak opisano niżej w Opcje ról. config.yaml musi mieć rolę admin i rolę default, a strona ról pokazuje obie jako Wymagane.

Przed wersją 7.0.0 default nazywała się public, a stara nazwa nadal działa:

W formularzu roles: [public] nadal pasuje do każdego użytkownika, więc formularze w Twoich repozytoriach nie wymagają zmian.
W config.yaml rola o nazwie public jest przy wczytywaniu konfiguracji przemianowywana w pliku na default. Zmienia się tylko nazwa, najpierw tworzona jest kopia zapasowa konfiguracji, a konfiguracja trzymana w repozytorium ma potem zmianę do wypchnięcia.
W szablonie ytt szablon nie jest przepisywany: przemianowywana jest konfiguracja, którą generuje, a ostrzeżenie w dzienniku prosi o zmianę nazwy roli także w szablonie. Wersja 8 odrzuci tam rolę public.

Konfiguracja z rolą default i rolą public jednocześnie jest odrzucana, bo to ta sama rola.

Obiekt Role

Każdy wpis listy roles:

A role allows RBAC. Each role has 1 or more groups (local or ldap). Except the default role (public its old name), which has no groups.
The default and admin roles are mandatory.

Atrybut	Komentarze
name string / required / unique	The name of the role alphanumeric + dash + underscore + space The name of a role has to be unique. The `default` and `admin` roles are mandatory.
groups array / required	Groups A group (local, ldap or entraid) A list of groups. They must be in the format of `local/groupname` or `ldap/groupname` or `entraid/groupname` A Microsoft Entra ID group can be named by its object id, `entraid/<object id>`: unique, where two groups can share a display name. Both work ; the object id is the one to prefer. `azuread/`, the Microsoft Entra ID prefix of before 7.3, still works the same as `entraid/` (deprecated, removed in 8.0) ; the roles editor writes `entraid/`.
users array / required added in version 4.0.10	User A user (local, ldap or entraid) A list of local or ldap users. They must be in the format of `local/username` or `ldap/username` or `entraid/username` (`azuread/username` before 7.3, still accepted)
credentials array added in version 7.0.0	The credentials this role may use regular expressions, matching a whole credential name Limits the credentials a user of this role may use: those a job passes to a playbook or a template (the form’s `credentials`, `ansibleCredentials`, `vaultCredentials`, a credential field), and those a form query or `fnCredentials` reads while the user fills in a form. Each entry is a regular expression that must match the whole name ; `__self__` is AnsibleForms’ own database. A user none of whose roles lists credentials may use every credential, as before. Once one of their roles lists them, they may use what any of the roles that list them allows. The `admin` role is never limited. A launch that needs a credential the roles do not allow is refused before the job is created.
secretStores array added in version 7.0.0	The secret stores this role may read inline secret store names Limits the secret stores a user of this role may read through an inline reference (`vault:<path>`, `secret:<store>:<ref>`) in a credential map, a query or `fnCredentials`. When a role limits the credentials and none limits the stores, an inline reference must match a credential pattern itself: it is no way around them. Combined across roles as `credentials`.
runners array added in version 7.0.0	The runners this role may run jobs on runner names Limits the runners a job of a user of this role may run on: the form’s `runner`, or the default runner when it names none. Combined across roles as `credentials`.
options object added in version 5.0.8	Role options Key value pairs Since version 5.0.8 you can add specific role options. The options are used to enable or disable certain features for a role. The options are: showDesigner: The user can see the designer allowFormDesign: The user can edit the forms config in the designer (categories, constants, forms: save, restore, pull and push the forms repositories). Without it the designer shows them read-only. Default true. (Added in 7.3.0) designAllForms: The designer shows and edits every form. Without it, only the forms whose `roles` hold one of the user’s roles: the others are left out (never named, a name taken by one is only said to be taken, a form of theirs naming one as a subform shows nothing of it). The subforms no hidden form uses (new ones included) are theirs to edit, a subform a hidden form uses as well as one of theirs is shown read only, and a form saved (a subform aside) must keep one of their roles. A file holding several forms keeps the hidden ones as they are, restoring a backup needs this option, and the form files are left out of the designer’s other explorers (a repository’s whole tree, as the workflows show it). The forms list leaves out the warning of a form name defined twice unless both copies are theirs, and the settings pages’ Forms tabs and a credential’s Used by tab, reached with a part of the settings only (not showSettings), list only the forms their designer shows. Limits the forms only (playbooks and workflows have designAllPlaybooks and designAllWorkflows); inventories, vars files, categories and constants stay visible to every designer. Off, the user may not run a raw expression either (POST /api/v2/expression with an `expression` of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0) allowPlaybookDesign: The user can edit the playbooks in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.0.0) designAllPlaybooks: Show and edit every playbook in the designer; without it, only the playbooks used by the forms the user can see, and the ones no form uses yet. A form uses a playbook by its `playbook` (with `playbookSubPath`), its ansible steps and the job template nodes of the workflows it runs (on the app or an rte runner); the forms it can see follow designAllForms. A hidden playbook is never listed nor read: it answers as a missing file, or as a file there already, and a form of theirs naming one, or a workflow file whose nodes run one, is refused. Edit Playbooks still decides whether the shown ones can be changed. Off, the user may not run a raw expression either (POST /api/v2/expression with an `expression` of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0) allowWorkflowDesign: The user can edit the workflows in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0) designAllWorkflows: Show and edit every workflow in the designer; without it, only the workflows used by the forms the user can see, and the ones no form uses yet. A form uses the workflow file it runs (`workflow`) and the nested workflows that one runs (every workflow a reference may mean, when several have its name); the forms it can see follow designAllForms. A hidden workflow file is never listed nor read (nor named in a credential’s Used by tab, without showSettings): it answers as a missing file, or as a file there already, and a form of theirs naming one, or a workflow file whose nodes run one, is refused. Edit Workflows still decides whether the shown ones can be changed. Off, the user may not run a raw expression either (POST /api/v2/expression with an `expression` of its own, as the designer previews a form not saved yet): it could read the files hidden from them. The expressions of the saved forms still run, and showSettings still allows a raw one. A form saved may not gain an expression or a query the server runs that it does not have already (403). Default true, always true for admins. (Added in 7.5.0) allowInventoryDesign: The user can edit the inventories in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0) allowVarsFileDesign: The user can edit the vars files in the designer (save, new, remove, push). Without it the designer shows them read-only. Default true. (Added in 7.1.0) showSettings: The user can see the settings page showDebugButtons: The user can see the debug buttons on a form showExtravars: The user can see the extravars on a form showLogs: The user can see the server log (Settings > Server log) showAuditLog: The user can see the audit log (Settings > Audit log) without the other settings. Default: admins. (Added in 7.3.0) showAppearanceSettings: The user can change Settings > Appearance (defaults, name, logo, icon, links, environment label, announcements) without the other settings. Default false. (Added in 7.3.0) showConnectionsSettings: The user can manage Settings > Connections (repositories, credentials, secret stores, runners, SSH, notifications, chat assistant, MCP, syslog) without the other settings. Default false. (Added in 7.3.0) showJobs: The user can see the jobs page. Default true. showArtifacts: The user can see the artifacts an AWX job returns. Default true. allowFileUploads: The user can upload files through a form’s file fields. Without it the field is read-only and the upload is refused. Default true. (Added in 7.3.0) allowApiTokens: The user can make API tokens (Profile > API token), living up to API_TOKEN_MAX_DAYS. Default false (true for a role that only sets extendedTokenExpiration, as before this option). (Added in 7.3.0) extendedTokenExpiration: With allowApiTokens, the user can also make API tokens that never expire. Default false. showAllJobLogs: The user can see all job logs (not only his own) (Added in 5.0.9) admin: The role’s users are admins, as the admin role’s own: every form, the designer, the settings and the users, whatever the role is called (platformAdmins, infra_admins). Only an admin turns it on for a role with members or adds members to such a role, and a save that would take admin away from the admin saving it is refused. Never on the default role. Default false ; always true for the admin role. (Added in 7.6.0) allowLogin: The user can login. allowBackupOps: The user can perform database operations, such as backup and restore. allowVerboseMode: The user can enable verbose mode on ansible forms. allowJobRelaunch: The user can relaunch jobs with pre-filled form data from previous submissions. allowJobDeletion: The user can delete jobs (their own ; an admin every job). Without it the job history stays whole. Default true. (Added in 7.3.0) manageAllJobs: The user can abort, delete and relaunch the jobs of every user, not only their own, without the admin role (delete and relaunch also need allowJobDeletion and allowJobRelaunch). Default: admins. (Added in 7.3.0) allowScheduledJobs: The user can create and manage scheduled jobs (recurring cron or one-time). Default for admins only. Grant it only to roles you would trust as admins: every user with this option sees and can change all schedules, not only their own, and a schedule they create runs with admin rights, for any form. (Added in 6.1.5) allowStoredJobs: The user can store and load job data for later use. (Added in 6.1.5) allowStoredJobsShare: The user can share a stored job, so other users can load it from the form (they need allowStoredJobsViewAll). The stored job stays theirs: only they (and the admins) can change or delete it. Default: admins. (Added in 7.5.0) allowStoredJobsViewAll: The user sees the stored jobs other users shared, in the Load list of a form they may open, and can load them. Default: admins. (Added in 7.5.0) allowPlannedJobs: The user can plan a one-time run of a form they may run (“Run later”). The job runs as that user, not as admin, and they cannot see or change other schedules. (Added in 6.1.5) allowChat: The user can use the chat assistant (when it is enabled). Default true. (Added in 6.5.0) allowMcp: The user can use the MCP server from an AI agent (when it is enabled). Defaults to the role’s allowChat. (Added in 7.0.0) When options are not set, the admin role will have all options. When options are set on the default role, they will have the lowest precedence and can be used as default options for all roles. You can add options on role level, which will override the default role options.
Examples
1) Roles `roles: - name: admin # is mandatory groups: - local/admins - ldap/Domain Admins - name: operator groups: - local/operator users: - entraid/mike - name: architect groups: - local/architect options: showDesigner: true # architects can see the designer showLogs: true # architects can see the logs - name: demo groups: - local/demo - name: default # is mandatory groups: [] options: showDebugButtons: true # everyone can see the debug buttons showExtraVars: true # everyone can see the extravars`

Opcje ról

options roli włączają lub wyłączają funkcje dla jej członków. Od wersji 7.3.0 strona roli pokazuje je w czterech grupach, każdą opcję z (i), które mówi, co daje, tym samym tekstem, który pokazuje widok Uprawnienia w profilu:

Opcja	Pozwala użytkownikowi	Domyślnie
Ustawienia
`showSettings`	Widzieć i zmieniać każdą stronę ustawień; dziennik serwera i kopie zapasowe mają własne opcje	Tylko admini
`showAppearanceSettings`	Zmieniać ustawienia wyglądu, bez pozostałych ustawień (od 7.3.0)	Wyłączona
`showConnectionsSettings`	Zarządzać ustawieniami połączeń (poświadczenia, runnery i inne), bez pozostałych ustawień (od 7.3.0)	Wyłączona
`showLogs`	Widzieć dziennik serwera	Tylko admini
`showAuditLog`	Widzieć dziennik audytu, bez pozostałych ustawień (od 7.3.0)	Tylko admini
`allowBackupOps`	Tworzyć kopię zapasową bazy danych i ją przywracać	Tylko admini
Projektant
`showDesigner`	Widzieć projektanta i z niego korzystać	Tylko admini
`allowFormDesign`	Edytować konfigurację formularzy w projektancie: kategorie, stałe i formularze. Bez niej tylko do odczytu (od 7.3.0)	Włączona
`designAllForms`	Widzieć i edytować każdy formularz w projektancie. Bez niej tylko formularze ról użytkownika (od 7.5.0)	Włączona
`allowPlaybookDesign`	Edytować playbooki w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu	Włączona
`designAllPlaybooks`	Widzieć i edytować każdy playbook w projektancie. Bez niej tylko te, których używają formularze użytkownika lub których nie używa jeszcze żaden formularz (od 7.5.0)	Włączona
`allowWorkflowDesign`	Edytować workflowy w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu	Włączona
`designAllWorkflows`	Widzieć i edytować każdy workflow w projektancie. Bez niej tylko te, których używają formularze użytkownika lub których nie używa jeszcze żaden formularz (od 7.5.0)	Włączona
`allowInventoryDesign`	Edytować inwentarze w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu	Włączona
`allowVarsFileDesign`	Edytować pliki zmiennych w projektancie: zapisywać, tworzyć, usuwać i wypychać je. Bez niej tylko do odczytu	Włączona
Zadania
`showJobs`	Widzieć stronę zadań	Włączona
`showAllJobLogs`	Widzieć zadania każdego użytkownika, nie tylko własne	Tylko admini
`manageAllJobs`	Przerywać, usuwać i ponownie uruchamiać zadania każdego użytkownika; usuwanie i ponowne uruchamianie wymagają też dwóch opcji poniżej (od 7.3.0)	Tylko admini
`showExtravars`	Widzieć extravars formularza i zadania	Włączona
`showDebugButtons`	Widzieć przyciski debugowania w formularzu	Włączona
`showArtifacts`	Widzieć artefakty zadania: to, co zwraca zadanie AWX, lub to, co playbook zebrał przez `set_stats`	Włączona
`allowVerboseMode`	Uruchamiać zadania w trybie verbose	Włączona
`allowJobRelaunch`	Ponownie uruchamiać zadanie z danymi formularza z wcześniejszego uruchomienia	Tylko admini
`allowJobDeletion`	Usuwać zadania: własne albo, z `manageAllJobs`, każdego użytkownika. Bez niej historia zadań pozostaje kompletna (od 7.3.0)	Włączona
`allowScheduledJobs`	Tworzyć harmonogramy cykliczne i jednorazowe oraz nimi zarządzać na stronie Harmonogramy (zobacz ostrzeżenie poniżej)	Tylko admini
`allowPlannedJobs`	Zaplanować jednorazowe uruchomienie zadania o ustalonej porze (Uruchom później)	Włączona
`allowStoredJobs`	Zapisywać dane formularza i wczytywać je później	Włączona
Dostęp i integracje
`allowLogin`	Logować się do AnsibleForms	Włączona
`allowChat`	Używać asystenta czatu, gdy jest włączony	Włączona
`allowMcp`	Używać serwera MCP z agenta AI, gdy jest włączony	`allowChat` danej roli
`allowFileUploads`	Przesyłać pliki przez pola plików formularza (od 7.3.0)	Włączona
`allowApiTokens`	Tworzyć tokeny API dla skryptów, do najdłuższego czasu życia, na jaki pozwala instancja (od 7.3.0)	Wyłączona
`extendedTokenExpiration`	Tworzyć też tokeny API, które nigdy nie wygasają; wymaga `allowApiTokens`	Wyłączona

Niektóre opcje obejmują inne, a strona roli pokazuje te objęte jako włączone i wyszarzone:

showSettings daje też showAppearanceSettings, showConnectionsSettings i showAuditLog.
manageAllJobs daje też showAllJobLogs, bo działanie na zadaniach każdego użytkownika oznacza ich widzenie.
Opcje projektowania mają znaczenie tylko z showDesigner, a extendedTokenExpiration tylko z allowApiTokens.

Do wersji 7.2.0 showAllJobLogs pozwalało też przerywać i usuwać wyświetlane zadania; od 7.3.0 wymaga to manageAllJobs. Rola sprzed 7.3.0 z extendedTokenExpiration i bez allowApiTokens dostaje allowApiTokens, więc zachowuje swoje tokeny.

designAllForms, designAllPlaybooks i designAllWorkflows są zawsze włączone dla adminów, a to, co projektant pokazuje użytkownikowi bez nich, opisuje Ograniczeni projektanci.

Tylko admini oznacza włączoną dla użytkowników z rolą admin i wyłączoną dla wszystkich pozostałych. Gdy użytkownik pasuje do kilku ról, opcje łączą się następująco:

Między rolami użytkownika opcja jest włączona tylko wtedy, gdy zgadza się każda rola, która ją ustawia: jawne false wygrywa.
Rola default uzupełnia opcje, których nie ustawia żadna inna rola użytkownika, więc może zawierać wartości domyślne dla wszystkich.
Opcje nigdzie nieustawione przyjmują wartość domyślną z tabeli.

showExtraVars, z wielkim V, jest akceptowane jako inna pisownia showExtravars; gdy którakolwiek pisownia ma wartość false, opcja jest wyłączona.

Traktuj allowScheduledJobs jak opcję na poziomie admina. Harmonogramy nie należą do użytkownika, który je utworzył: każdy użytkownik z tą opcją widzi i może zmieniać wszystkie harmonogramy. Harmonogram działa też z uprawnieniami admina, dla dowolnego formularza, niezależnie od uprawnień twórcy. Nadawaj ją tylko rolom, którym ufasz jak adminom.

allowLogin: false w roli default blokuje każdego użytkownika, którego pozostałe role nie ustawiają allowLogin: true, łącznie z adminami. Przed zapisem przywróć ją w rolach, które muszą się logować.