@nocobase/plugin-ai 2.1.31 → 2.2.0-alpha.10

package/client-v2.d.ts

@@ -1 +1,2 @@
 export * from './dist/client-v2';
+export { default } from './dist/client-v2';

package/dist/ai/docs/nocobase/api/app/env.md

@@ -107,7 +107,7 @@ For example, to add the `hello` plugin to the `my-nocobase-app` project, the ful
 PLUGIN_PACKAGE_PREFIX can be configured as:
 
 ```bash
-PLUGIN_PACKAGE_PREFIX=@nocobase/plugin-,@nocobase-preset-,@my-nocobase-app/plugin-
+PLUGIN_PACKAGE_PREFIX=@nocobase/plugin-,@nocobase/preset-,@my-nocobase-app/plugin-
 ```
 
 Then the mapping between plugin names and package names is as follows:

package/dist/ai/docs/nocobase/api/cli/index.md

@@ -1,7 +1,7 @@
 ---
 title: 'NocoBase CLI'
-description: 'NocoBase CLI (`nb` command) reference: initialization, backup and restore, configuration, environment management, app runtime, source code, database, plugins, commercial license, API, CLI self-update, and Skills management.'
-keywords: 'NocoBase CLI,nb,command line,command reference,backup,restore,environment management,plugin management,commercial license,API'
+description: 'NocoBase CLI (`nb` command) reference: initialization, backup and restore, configuration, environment management, app runtime, portal, source code, database, plugins, commercial license, API, CLI self-update, and Skills management.'
+keywords: 'NocoBase CLI,nb,command line,command reference,backup,restore,environment management,Portal,plugin management,commercial license,API'
 ---
 
 # NocoBase CLI
@@ -39,6 +39,7 @@ The following command groups are shown in `nb --help`:
 | [`nb env`](./env/index.md)           | Manage NocoBase project environments, the current env, status, details, and runtime commands. |
 | [`nb license`](./license/index.md)   | Manage commercial licenses and licensed plugins.                                              |
 | [`nb plugin`](./plugin/index.md)     | Manage plugins in the selected NocoBase env.                                                  |
+| [`nb portal`](./portal/index.md)     | Manage portals: configure, create, develop, sync source, deploy, and destroy.                       |
 | [`nb scaffold`](./scaffold/index.md) | Generate scaffolding for NocoBase plugin development.                                         |
 | [`nb self`](./self/index.md)         | Check or update NocoBase CLI itself.                                                          |
 | [`nb session`](./session/index.md)   | Configure `NB_SESSION_ID` so the current env is isolated by shell or agent runtime.           |
@@ -70,6 +71,8 @@ nb backup --help
 nb config --help
 nb api resource --help
 nb license --help
+nb portal --help
+nb portal config --help
 ```
 
 ## Examples
@@ -127,6 +130,15 @@ nb license status -e app1
 nb license plugins list -e app1
 ```
 
+Create and develop a portal:
+
+```bash
+nb portal create customer -e app1 --yes
+nb portal config customer -e app1 --yes --source-storage git --git-repo git@github.com:nocobase/customer-portal.git
+nb portal dev customer -e app1 --yes
+nb portal deploy customer -e app1 --yes
+```
+
 Create and download a backup:
 
 ```bash

package/dist/ai/docs/nocobase/api/cli/portal/config.md

@@ -0,0 +1,44 @@
+---
+title: "nb portal config"
+description: "nb portal config command reference: update source storage and Git source configuration for a portal."
+keywords: "nb portal config,NocoBase CLI,Portal"
+---
+
+# nb portal config
+
+Update the local portal source configuration and sync it to the remote portal record when possible
+
+## Usage
+
+```bash
+nb portal config <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+| `--source-storage` | `nocobase` \| `git` | Where portal source code is managed. |
+| `--git-repo` | string | Git repository URL used with `--source-storage=git`. |
+| `--git-branch` | string | Git branch used with `--source-storage=git`. |
+| `--git-path` | string | Directory inside the Git repository; defaults to the repository root (`.`). |
+
+## Examples
+
+```bash
+nb portal config customer --source-storage nocobase
+nb portal config customer --source-storage git --git-repo git@github.com:nocobase/customer-portal.git
+nb portal config customer --git-branch main --git-path portals/customer
+```
+
+## Notes
+
+Pass at least one configuration flag. The local workspace must already exist; use `nb portal create` or `nb portal pull` first. If the remote portal record exists, the configuration is synced to it; otherwise only `portal.config.json` is updated locally.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/create.md

@@ -0,0 +1,48 @@
+---
+title: "nb portal create"
+description: "nb portal create command reference: create a local portal from a template and create or update the portal record."
+keywords: "nb portal create,NocoBase CLI,Portal"
+---
+
+# nb portal create
+
+Create a local portal from a template and create or update the portal record
+
+## Usage
+
+```bash
+nb portal create <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--template` | string | Template package, local path, or `file://` URL. Default: `@nocobase/portal-template-default`. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+| `--title` | string | Portal display title. |
+| `--force` | boolean | Delete the existing workspace and recreate it. |
+| `--source-storage` | `nocobase` \| `git` | Where portal source code is managed. Default: `nocobase`. |
+| `--git-repo` | string | Git repository URL used with `--source-storage=git`. |
+| `--git-branch` | string | Git branch used with `--source-storage=git`. |
+| `--git-path` | string | Directory inside the Git repository; defaults to the repository root (`.`). |
+
+## Examples
+
+```bash
+nb portal create customer
+nb portal create customer --template @nocobase/portal-template-default
+nb portal create customer --env dev --yes
+nb portal create customer --source-storage git --git-repo git@github.com:nocobase/customer-portal.git
+```
+
+## Notes
+
+The command writes `.env`, `.env.local`, and `portal.config.json`. If the template contains `package.json`, it runs `pnpm install`. Portal names must use lowercase letters, numbers, underscores, or hyphens, and start with a lowercase letter or number.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/deploy.md

@@ -0,0 +1,39 @@
+---
+title: "nb portal deploy"
+description: "nb portal deploy command reference: build and deploy a portal."
+keywords: "nb portal deploy,NocoBase CLI,Portal"
+---
+
+# nb portal deploy
+
+Build and deploy the specified portal
+
+## Usage
+
+```bash
+nb portal deploy <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+
+## Examples
+
+```bash
+nb portal deploy customer
+nb portal deploy customer --env dev --yes
+```
+
+## Notes
+
+The command refreshes `.env` and `.env.local`, runs `pnpm build`, and expects `dist/index.html`. For `local` and `docker` envs, it syncs the portal record and uses the local or volume-mounted `dist`; for `http` envs, it uploads the packed `dist` through the API.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/destroy.md

@@ -0,0 +1,41 @@
+---
+title: "nb portal destroy"
+description: "nb portal destroy command reference: delete a portal record and its local workspace."
+keywords: "nb portal destroy,NocoBase CLI,Portal"
+---
+
+# nb portal destroy
+
+Delete the portal record and local workspace
+
+## Usage
+
+```bash
+nb portal destroy <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip confirmation prompts. |
+| `--force` | boolean | Ignore missing portal records or workspace directories. |
+
+## Examples
+
+```bash
+nb portal destroy customer --yes
+nb portal destroy customer --env dev --yes
+nb portal destroy customer --force --yes
+```
+
+## Notes
+
+This command affects both the remote portal record and the local workspace. In non-interactive mode, pass `--yes`. Use `--force` to ignore missing records or local files.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/dev.md

@@ -0,0 +1,39 @@
+---
+title: "nb portal dev"
+description: "nb portal dev command reference: start a portal in development mode."
+keywords: "nb portal dev,NocoBase CLI,Portal"
+---
+
+# nb portal dev
+
+Start development mode for the specified portal
+
+## Usage
+
+```bash
+nb portal dev <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+
+## Examples
+
+```bash
+nb portal dev customer
+nb portal dev customer --env dev --yes
+```
+
+## Notes
+
+The workspace must contain `package.json`. The command refreshes `.env` and `.env.local`, then runs `pnpm dev`. `ssh` envs are not supported in the current version.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/index.md

@@ -0,0 +1,136 @@
+---
+title: "nb portal"
+description: "nb portal command reference: manage portals, including configuration, creation, development, source sync, deployment, and deletion."
+keywords: "nb portal,NocoBase CLI,Portal,workspace,source storage,deploy"
+---
+
+# nb portal
+
+`nb portal` manages portals. A portal can have its own frontend source, entry path, and deployment output; this command group connects the portal record in NocoBase with the local workspace and source storage.
+
+A typical flow is to create a local workspace, start development mode, push source changes to source storage, and then build and deploy. If you are taking over an existing portal, pull it locally first.
+
+## Usage
+
+```bash
+nb portal <command>
+```
+
+## Subcommands
+
+| Command | Description |
+| --- | --- |
+| [`nb portal config`](./config.md) | Update the local portal source configuration and sync it to the remote portal record when possible |
+| [`nb portal create`](./create.md) | Create a local portal from a template and create or update the portal record |
+| [`nb portal deploy`](./deploy.md) | Build and deploy the specified portal |
+| [`nb portal destroy`](./destroy.md) | Delete the portal record and local workspace |
+| [`nb portal dev`](./dev.md) | Start development mode for the specified portal |
+| [`nb portal info`](./info.md) | Show details for the specified portal record and local workspace |
+| [`nb portal list`](./list.md) | List portal records and local workspace sync status |
+| [`nb portal pull`](./pull.md) | Pull portal source from source storage into the local workspace |
+| [`nb portal push`](./push.md) | Push local portal source changes to source storage |
+
+## Typical Flow
+
+Create a portal named `customer`:
+
+```bash
+nb portal create customer -e dev --yes
+```
+
+Start local development mode:
+
+```bash
+nb portal dev customer -e dev --yes
+```
+
+Inspect the local workspace and remote record:
+
+```bash
+nb portal info customer -e dev --yes
+nb portal list -e dev --yes
+```
+
+Push source and deploy:
+
+```bash
+nb portal push customer -e dev --yes --message "Update customer portal"
+nb portal deploy customer -e dev --yes
+```
+
+Take over an existing portal:
+
+```bash
+nb portal list -e dev --yes
+nb portal pull customer -e dev --yes
+nb portal dev customer -e dev --yes
+```
+
+Switch source storage:
+
+```bash
+nb portal config customer -e dev --yes --source-storage git --git-repo git@github.com:nocobase/customer-portal.git
+nb portal push customer -e dev --yes --message "Move customer portal source to Git"
+```
+
+## source storage
+
+When creating a portal, choose where the source code is managed:
+
+| Mode | Description |
+| --- | --- |
+| `nocobase` | Default mode. Source code is managed by NocoBase source storage. |
+| `git` | Source code is stored in a Git repository, configured with `--git-repo`, `--git-branch`, and `--git-path`. |
+
+For quick creation and development, the default `nocobase` storage is usually enough. Use `git` when the portal source should be reviewed, versioned, or built through an existing team workflow.
+
+Source configuration is written to `portal.config.json` in the local workspace. `create`, `pull`, and `config` maintain this file; `push` and `deploy` read it to sync source or deployment output.
+
+## Env Types
+
+`nb portal` currently supports `local`, `docker`, and `http` envs:
+
+| Mode | Description |
+| --- | --- |
+| `local` | The workspace and app storage are on the current machine. With default `nocobase` storage, `pull`/`push` usually do not need extra sync. |
+| `docker` | The workspace is shared with the app through a Docker volume. With default `nocobase` storage, `pull`/`push` usually do not need extra sync. |
+| `http` | Source and deployment output are synced through APIs. `pull` downloads a source archive, and `push` uploads one. |
+
+`ssh` envs do not support portal management in the current version.
+
+## Local Workspace Path
+
+Portals are stored under the selected env storage:
+
+```text
+<storagePath>/portals/<app>/<portal>
+```
+
+The main app access path is usually:
+
+```text
+<appPublicPath>/x/<portal>/
+```
+
+A sub-app access path is usually:
+
+```text
+<appPublicPath>/x/apps/<app>/<portal>/
+```
+
+## Env Confirmation
+
+Most `nb portal` subcommands support `--env` and `--yes`:
+
+| Flag | Description |
+| --- | --- |
+| `--env`, `-e` | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | Skip cross-env confirmation when an explicit `--env` targets a different env from the current env. |
+
+In scripts or AI agent workflows, pass `--env` and `--yes` explicitly to avoid stopping at an interactive confirmation.
+
+## Related Commands
+
+- [`nb env`](../env/index.md)
+- [`nb app`](../app/index.md)
+- [`nb source`](../source/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/info.md

@@ -0,0 +1,41 @@
+---
+title: "nb portal info"
+description: "nb portal info command reference: show portal record and local workspace details."
+keywords: "nb portal info,NocoBase CLI,Portal"
+---
+
+# nb portal info
+
+Show details for the specified portal record and local workspace
+
+## Usage
+
+```bash
+nb portal info <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+| `--json-output`, `-j` | boolean | Print portal details as JSON. |
+
+## Examples
+
+```bash
+nb portal info customer
+nb portal info customer --env dev --yes
+nb portal info customer --json-output
+```
+
+## Notes
+
+Text output includes name, URL, portal type, local path, enabled status, and local sync status. `--json-output` prints `name`, `url`, `portalType`, `localPath`, `enabled`, `sourceStorage`, and `localSynced`. You can query by `routeName` or `uid`.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/list.md

@@ -0,0 +1,40 @@
+---
+title: "nb portal list"
+description: "nb portal list command reference: list portal records and local workspace sync status."
+keywords: "nb portal list,NocoBase CLI,Portal"
+---
+
+# nb portal list
+
+List portal records and local workspace sync status
+
+## Usage
+
+```bash
+nb portal list [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+| `--json-output`, `-j` | boolean | Print portal records as JSON. |
+
+## Examples
+
+```bash
+nb portal list
+nb portal list --env dev --yes
+nb portal list --json-output
+```
+
+## Notes
+
+The list shows name, URL, portal type, source storage, local path, enabled status, and local sync status. Only `ai` portals have local workspace sync checks; other portal types show an empty sync status.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/pull.md

@@ -0,0 +1,43 @@
+---
+title: "nb portal pull"
+description: "nb portal pull command reference: pull portal source into the local workspace."
+keywords: "nb portal pull,NocoBase CLI,Portal"
+---
+
+# nb portal pull
+
+Pull portal source from source storage into the local workspace
+
+## Usage
+
+```bash
+nb portal pull <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+| `--force` | boolean | Delete the existing local workspace and pull it again. |
+| `--install` / `--no-install` | boolean | Run `pnpm install` after pulling source. Enabled by default. |
+
+## Examples
+
+```bash
+nb portal pull customer
+nb portal pull customer --env prod --yes
+nb portal pull customer --force
+nb portal pull customer --no-install
+```
+
+## Notes
+
+When the pulled workspace contains `package.json`, `pnpm install` runs by default. Use `--no-install` to skip it. Git source storage clones the configured repo and branch, then copies `--git-path`. With default `nocobase` storage, `local` and `docker` envs are usually no-op; `http` envs download a source archive through the API.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/api/cli/portal/push.md

@@ -0,0 +1,41 @@
+---
+title: "nb portal push"
+description: "nb portal push command reference: push local portal source changes to source storage."
+keywords: "nb portal push,NocoBase CLI,Portal"
+---
+
+# nb portal push
+
+Push local portal source changes to source storage
+
+## Usage
+
+```bash
+nb portal push <portal> [flags]
+```
+
+## Flag
+
+| Flag | Type | Description |
+| --- | --- | --- |
+| `<portal>` | string | Portal name or slug. |
+| `--env`, `-e` | string | CLI env name. If omitted, the current env is used. |
+| `--yes`, `-y` | boolean | Skip cross-env confirmation. |
+| `--message`, `-m` | string | Source update message; for Git-managed source, it is used as the Git commit message. |
+
+## Examples
+
+```bash
+nb portal push customer
+nb portal push customer --env prod --yes
+nb portal push customer --message "Update customer portal"
+```
+
+## Notes
+
+The command reads `portal.config.json` and syncs that configuration to the remote portal record first. Git source storage clones the configured repo, copies the local workspace into `--git-path`, commits, and pushes. With default `nocobase` storage, `local` and `docker` envs are usually no-op; `http` envs upload a source archive through the API.
+
+## Related Commands
+
+- [`nb portal`](./index.md)
+- [`nb env`](../env/index.md)

package/dist/ai/docs/nocobase/file-manager/stable-url.md

@@ -0,0 +1,87 @@
+---
+pkg: '@nocobase/plugin-file-manager'
+title: "Stable URL (proxy URL)"
+description: "Explains NocoBase stable file URLs, access permissions, redirects, temporary Office preview URLs, and behavior across file-related features."
+keywords: "stable URL,proxy URL,permanent URL,file access,file permissions,Office preview,NocoBase"
+---
+
+# Stable URL
+
+Files managed by a NocoBase storage engine are accessed through a **stable URL**. The URL first reaches NocoBase, where the file record and access permissions are checked, and then redirects to the actual URL generated by the storage engine.
+
+## URL format
+
+```text
+/files/<app>/<dataSource>/<collection>/<id><extname>
+```
+
+For example:
+
+```text
+/files/main/main/attachments/42.pdf
+```
+
+When `APP_PUBLIC_PATH=/nocobase` is configured, the URL starts with `/nocobase/files/`. The path identifies the app, data source, file collection, record ID, and extension. The ID and extension cannot be changed after creation, which keeps the URL stable for the lifetime of the record.
+
+## URL variants
+
+| Purpose | URL | Behavior |
+|---|---|---|
+| Open or embed | `/files/.../42.pdf` | Checks permission and redirects to the actual file URL |
+| Preview | `/files/.../42.png?preview=1` | Redirects to the preview or thumbnail URL |
+| Download | `/files/.../42.pdf?download=1` | Redirects with download semantics |
+| Office preview | `/files/.../42.xlsx?temporaryAccessToken=...` | Allows Microsoft Office Online Viewer to fetch one file for a short time |
+
+:::tip
+
+Use the `url` and `preview` values returned by NocoBase. Application code normally should not construct `/files` URLs or their query parameters.
+
+:::
+
+## Behavior across NocoBase
+
+- Attachment fields and file collections return stable URLs after upload and when records are queried
+- [HTTP API](./http-api.md) responses no longer expose local paths, storage domains, or presigned download URLs
+- Markdown uploads store the stable URL, including files in private S3, OSS, COS, or S3 Pro storage
+- Attachment URL fields store a stable URL for managed uploads, while manually entered external URLs remain unchanged
+- Image, PDF, audio, video, and text previews use the stable URL and the current NocoBase login session
+- Public forms grant limited access to files uploaded in the current public-form browser session; this does not create a generally public link
+
+## Office preview
+
+Microsoft Office Online Viewer fetches the file from Microsoft servers and cannot use the user's NocoBase cookie. When the user opens an Office preview, NocoBase first checks the user's file permission and then issues a temporary URL for that file.
+
+The URL is valid for 10 minutes by default. `TEMPORARY_FILE_ACCESS_EXPIRES_IN` may be set from 5 to 10 minutes. It is requested again when the preview is reopened and must never be saved in an attachment field, Markdown content, or a business record.
+
+## Permissions and redirects
+
+Logged-in requests use the current app credentials and role. After permission is granted, NocoBase responds with `302` and redirects to the local or object-storage URL.
+
+Stable URLs support `GET` and `HEAD`. Other methods return `405`. A command-line client must follow redirects, for example:
+
+```bash
+curl -L \
+  -H "Authorization: Bearer <JWT>" \
+  "https://example.com/files/main/main/attachments/42.pdf"
+```
+
+## Important notes
+
+- Stable does not mean public; recipients still need permission to view the file
+- Deleting the record or changing its app, data source, or collection context invalidates the old URL
+- Do not persist `temporaryAccessToken` or use it as a sharing link
+- Do not cache the `302 Location` as a permanent URL because storage signatures can expire
+- Do not rewrite the app, data source, collection, ID, or extension in the path
+- Reverse proxies must forward the `/files/` route under `APP_PUBLIC_PATH` to NocoBase. For subpath deployments, keep a compatible root-level `/files/` route as well. Configurations generated by the NocoBase CLI include both routes automatically
+- Deployments where the pages access the API cross-origin (with `API_BASE_URL` pointing to another origin) must add the page origin to `CORS_ORIGIN_WHITELIST`; otherwise the login cookie is never stored and stable URLs return `403` for lack of credentials. See [Environment Variables](../get-started/installation/env.md#api_base_url)
+- Use a different `hostname` for each independent NocoBase service instead of separating services only by port. Browser cookies are not isolated by port; see [Production Environment Deployment](../get-started/deployment/production.md)
+- Sub-apps in the same NocoBase deployment are distinguished by app name and do not need separate hostnames. However, an independent service on another port still needs hostname isolation if it contains a main app or sub-app with the same name
+- Custom `fetch()` code may also need object-storage CORS after following the redirect
+- Use a dedicated sharing or public-access feature when a long-lived public link is required
+
+## Related links
+
+- [HTTP API](./http-api.md) — Upload and query files through the API
+- [File preview](./file-preview/index.md) — Preview behavior for supported file types
+- [Office file preview](./file-preview/ms-office.md) — Configure Microsoft Office Online Viewer
+- [Storage engines](./storage/index.md) — Configure local and object storage