ENABLE_MCP
boolean
added in version 6.4.0 | Default:
0 | Enable the MCP server for AI agents
0, 1 Serves an MCP (Model Context Protocol) server on /api/v2/mcp, so an AI agent or an MCP client (a chat backend, an IDE) can list the forms a user may use, resolve their fields, launch jobs and follow them. Every request carries an AnsibleForms access token and runs as that user, with the same form roles and job visibility as in the browser. Changing it needs a restart. See the MCP page of the documentation. |
ENABLE_CHAT
boolean
added in version 6.5.0 | Default:
0 | Enable the chat assistant
0, 1 Shows a chat button on every page. The assistant fills in a form with the user by talking, through the same form engine as the browser, and launches it only when the user clicks the Launch button on the exact payload it was shown. It also needs a model provider on the Chat assistant settings page (or in the config seed), forms with enableForChat: true, and users whose roles allow allowChat (the default). Form definitions and the values being filled in are sent to that provider ; passwords, credentials and job output never are. Changing it needs a restart. See the Chat assistant page of the documentation. |
LAUNCH_VALIDATION
string
added in version 6.4.0 | Choices: - off (default)
- log
- enforce
| Check the field values of every launch against the form's validation rules
off, log, enforce Checks every launch from the browser or the REST API (POST /api/v2/job) on the server against the form’s validation rules - required, regex, minValue/maxValue, minLength/maxLength, minSize/maxSize, sameAs, in/notIn, validIf/validIfNot, valid YAML - with the same engine the browser and the MCP server use. The check runs the form’s expressions and queries again, as the user who launches, so it costs one extra evaluation of the form per launch. off (default) : no check, launches behave exactly as before.log : a launch that would be refused is logged as a warning and still runs. Use this first, to see in the log what enforcing would refuse.log also names the extravars keys where what the client sent differs from what the server builds (never their values).-
enforce : such a launch is refused with status 422 and the failing fields. A launch that sends no rawFormData (the v1 API, or a REST call that leaves it out) is refused as well, because its values cannot be checked. A valid launch runs the extravars and credentials the SERVER builds from the checked values, not the ones the client sent : computed fields (expressions, queries) are the server’s evaluation, and a file field must point at a real upload in UPLOAD_PATH. Wizard forms cannot be checked yet and are refused.
What the user saw is not always what runs. The server evaluates every computed field again at launch, a moment after the browser did, as the launching user. A value that depends on WHEN or WHERE it is evaluated can differ, and then the server’s value runs : - time :
fn.fnTime(), new Date(), a timestamp or a name built from it ; - outside data : a query,
fnRestAdvanced / fnSsh / fnDnsResolve, a file read - if the data changed in between ;
- the browser’s own settings : a
runLocal expression using the user’s timezone or locale (toLocaleString) runs with the server’s. The same goes for validation : a rule that reads such a field (notIn against a query’s result, validIf on a computed flag) is checked against the server’s value. Run log first : it names every extravars key where the client and the server differ, so you see which forms this affects before you enforce. The rows of a list field that were added or edited go through their subform on the server as well, with the form’s values as __parent__ : its rules are checked and its computed fields evaluated. Rows the list’s own expression produced, and rows marked deleted, are sent as they are - as in the browser. At most 500 rows are resolved per launch. Applied without a restart. A form can be made stricter with its own launchValidation property ; the stricter of the two wins. See the Launch validation page of the documentation for the whole picture : what is checked, list rows, uploads, passwords and how to roll it out. |
ENABLE_DB_QUERY_LOGGING
number
added in version 5.0.3 | | Enable the database query logging
0, 1 When you want to see the database queries that are executed, you can enable this option by setting this variable to 1.
introduced, due to massive amount of logging of database queries, which can be useful for debugging, but not for production. |
SHOW_DESIGNER
number
added in version 4.0.0 | | Enable the internal designer
0, 1 Although we encourage you to use an editor such as Visual Studio Code to edit the config.yaml file, preferably with some form of source control. Ansible Forms comes with an internal yaml designer.
And although only admins can see the designer, you might want to disable it completely by setting this variable to 0. |