Testing and Exporting Configurations

This page shows how you build a configuration with AI Studio itself and test it on a device before you roll it out.

Exporting from the app

You don't have to write your configuration plugin by hand. Set something up in AI Studio, export it, and paste the Lua fragment into your plugin.

Switch on "Settings" → "App Options" → "Show administration settings?" once. It reveals the "Enterprise Administration" section and an "Export configuration" button next to each of these:

What you can export	Where the button is	Offered for
LLM providers	The provider list in the settings	Providers you created yourself
Embedding providers	The provider list in the settings	As above, only while the data sources preview is on
Transcription providers	The provider list in the settings	Providers you created yourself
Profiles	The profile dialog in the settings	Profiles you created yourself
Chat templates	The chat template dialog in the settings	Templates you created yourself
ERI data sources	The data source list in the settings	ERI data sources that don't use Kerberos
Document analysis policies	The Document Analysis Assistant	The selected policy
Tools	"Tool Settings" in the settings	Every tool, see Tools and Web Access

Objects that your organization already manages have no export button: they came from a plugin to begin with. Local files and folders as data sources have none either, because they exist on one computer only.

The button copies the fragment to your clipboard. Paste it into your plugin after the line that creates the list it extends, such as CONFIG["LLM_PROVIDERS"] = {}.

• An export creates a new ID for the exported object. Exporting the same provider twice gives your colleagues two providers. Once an object is in your plugin, keep its ID and edit the rest. Document analysis policies are the exception: they keep their ID.
• Some exports ask first: whether to include an API key, token, or password in encrypted form (see Providers and API Keys), and whether a chat template keeps the paths of its attachments or copies the files into your plugin.
• A tokenizer travels as a path. When a provider uses a tokenizer of its own, the fragment names the copy that AI Studio keeps of it, relative to the data folder, such as tokenizers/chat_<ID>/tokenizer.json. A configuration plugin reads this path relative to its own folder. Copy the file into your plugin at the same path, or change the path. Without the file, AI Studio counts tokens with its default tokenizer.

Handing a whole plugin to a colleague is something else: the "Share" function on the "Plugins" page writes a .mwplugin archive. DataApp.AllowUserToSharePlugins controls it.

Importing an exported object

Not everything needs a configuration plugin. Somebody who built a good chat template can export it, and each colleague imports it as a template of their own: an "Import" button sits next to the "Add" button of each object in the table above, except tools.

• Values only. AI Studio reads the fragment with the rules of a configuration plugin but never runs it. A fragment that contains anything other than values, such as a function call, is refused.
• The object belongs to the user. It gets an ID of its own and belongs to no configuration, even if the fragment came from one.
• Checked before it is saved. Providers, profiles, chat templates, and data sources open in their usual form, filled in. A document analysis policy is added right away.
• Hints first. The dialog lists what the user should know, such as a preselected provider that doesn't exist on this computer, an API key that can't be decrypted, or local files that a chat template would attach.
• Secrets are decrypted only where your encryption secret is configured. Without it, a provider is imported without its key, and an ERI data source with a token or a password can't be imported.

Exporting needs "Show administration settings?"; importing doesn't.

Allowing or locking imports

Each of these settings is true by default:

Setting	Allows importing
DataApp.AllowUserToImportConfigurationSnippets	Anything at all
DataApp.AllowUserToImportProfile	Profiles
DataApp.AllowUserToImportLLMProvider	LLM providers
DataApp.AllowUserToImportEmbeddingProvider	Embedding providers
DataApp.AllowUserToImportTranscriptionProvider	Transcription providers
DataApp.AllowUserToImportChatTemplate	Chat templates
DataApp.AllowUserToImportERIDataSource	ERI data sources
DataApp.AllowUserToImportDocumentAnalysisPolicy	Document analysis policies

An import needs the first setting and the one of its type. A provider also needs what adding one by hand needs: DataApp.AllowUserToAddProvider and the setting of its kind, such as DataApp.AllowUserToAddLLMProvider. Importing plugin archives has settings of its own: DataApp.AllowUserToImportPlugins and, for configuration plugins, DataApp.AllowUserToImportConfigurationPlugins.

Testing on a device

Before you roll out a configuration, test it on a device. You need neither the configuration server nor the registry, policy files, or an encryption secret.

AI Studio has a folder for this, .config-tests, below the plugins folder in its data folder. What you place there counts as a configuration of your organization, exactly like a deployed one. In return, AI Studio empties the folder at every start, so a test lasts one session. Don't use the .config folder for tests: it belongs to your configuration server, and AI Studio removes everything there that your organization no longer references.

Staging a configuration

Place the files while AI Studio runs, because the test folder is emptied at every start:

1. Start AI Studio. It creates <data folder>/plugins/.config-tests/ if it doesn't exist yet.
2. Create a folder below it, such as .config-tests/department-draft/, and place your plugin.lua and icon.lua there. The folder name doesn't matter.
3. Place every further plugin of the archive in a subfolder, such as .config-tests/department-draft/translation-assistant/. This mirrors the archive you serve later.
4. AI Studio notices the files and loads them without a restart.

The data folder of each operating system is listed on the pages Deploying on Windows, Deploying on Linux, and Deploying on macOS. The "Information" page shows it too, and while a test configuration is active, it says so.

What behaves like the rollout:

• Approvals for assistant plugins are honored.
• What the test configuration manages is protected against local configuration plugins and against the user.
• When the test configuration has the same ID as a deployed one, the test wins. That's how you try out the next version of a configuration under its final ID.

What doesn't:

• A test doesn't survive a restart.
• It isn't tied to a configuration ID on the device.

Testing with a small group

To let colleagues take part, place the same folders on their devices while AI Studio runs, for example, with a script, your device management, or a login script. The data folder belongs to the user, so no administrator rights are needed. Everybody loses the test configuration at their next start, so repeat the step, or let your script run at every login.

Ending a test

Restart AI Studio, or delete your folder below .config-tests. AI Studio reacts right away: the approvals are gone, and every setting the test took over gets back the value it had before. There is no button for this on the "Plugins" page, because a test configuration is protected like a deployed one.

A word on security

A test configuration has the rights of a configuration of your organization without anybody having deployed it. Two things keep that in check: AI Studio empties the folder at every start, and no feature of AI Studio writes into it, so nobody can be talked into staging a configuration by opening a file.

Still, whoever can write into the data folder of a user can, until the next restart, act in the name of your organization, for example, approve assistant plugins. On managed devices, protect the data folder accordingly.

Where to go next

• Writing Configuration Plugins
• Managing Updates