@nocobase/plugin-ai 2.1.0-alpha.30 → 2.1.0-alpha.32
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/ai/docs/nocobase/ai-builder/security.md +1 -1
- package/dist/ai/docs/nocobase/api/cli/env/add.md +10 -2
- package/dist/ai/docs/nocobase/api/cli/env/current.md +29 -0
- package/dist/ai/docs/nocobase/api/cli/env/index.md +22 -4
- package/dist/ai/docs/nocobase/api/cli/env/list.md +11 -6
- package/dist/ai/docs/nocobase/api/cli/env/remove.md +3 -0
- package/dist/ai/docs/nocobase/api/cli/env/status.md +52 -0
- package/dist/ai/docs/nocobase/api/cli/env/use.md +10 -0
- package/dist/ai/docs/nocobase/api/cli/index.md +13 -1
- package/dist/ai/docs/nocobase/api/cli/session/id.md +28 -0
- package/dist/ai/docs/nocobase/api/cli/session/index.md +41 -0
- package/dist/ai/docs/nocobase/api/cli/session/remove.md +35 -0
- package/dist/ai/docs/nocobase/api/cli/session/setup.md +47 -0
- package/dist/ai/docs/nocobase/interface-builder/blocks/data-blocks/details.md +1 -1
- package/dist/ai/docs/nocobase/interface-builder/blocks/data-blocks/form.md +1 -1
- package/dist/ai/docs/nocobase/plugin-development/client/examples/custom-block.md +2 -2
- package/dist/ai/docs/nocobase/solution/crm/guide/guide-customers-emails.md +1 -1
- package/dist/ai/docs/nocobase/solution/crm/guide/guide-overview.md +2 -2
- package/dist/ai/docs/nocobase/tutorials/v2/01-getting-started.md +1 -1
- package/dist/ai/docs/nocobase/tutorials/v2/03-building-pages.md +2 -2
- package/dist/ai/docs/nocobase/tutorials/v2/04-forms-and-details.md +4 -4
- package/dist/ai/docs/nocobase/tutorials/v2/06-workflows.md +1 -1
- package/dist/ai/docs/nocobase/workflow/nodes/javascript.md +2 -2
- package/dist/client/index.js +1 -1
- package/dist/externalVersion.js +15 -15
- package/dist/locale/en-US.json +2 -0
- package/dist/locale/zh-CN.json +2 -0
- package/dist/node_modules/@langchain/xai/package.json +1 -1
- package/dist/node_modules/fs-extra/package.json +1 -1
- package/dist/node_modules/jsonrepair/package.json +1 -1
- package/dist/node_modules/just-bash/package.json +1 -1
- package/dist/node_modules/nodejs-snowflake/package.json +1 -1
- package/dist/node_modules/openai/package.json +1 -1
- package/dist/node_modules/zod/package.json +1 -1
- package/dist/server/ai-employees/ai-employee.js +11 -7
- package/dist/server/collections/lc-checkpoint-blobs.js +1 -1
- package/dist/server/collections/lc-checkpoint-writes.js +1 -1
- package/dist/server/collections/lc-checkpoints.js +1 -1
- package/dist/server/workflow/nodes/employee/files.d.ts +1 -0
- package/dist/server/workflow/nodes/employee/files.js +14 -4
- package/dist/server/workflow/nodes/employee/index.js +6 -4
- package/dist/server/workflow/nodes/employee/types.d.ts +2 -2
- package/package.json +2 -2
|
@@ -91,7 +91,7 @@ nb env auth local
|
|
|
91
91
|
|
|
92
92
|
`nb env auth` launches the browser login flow. After success, the CLI saves the authentication information to the current environment configuration, and you can then continue having the AI Agent call `nb api`.
|
|
93
93
|
|
|
94
|
-
The validity periods of OAuth access tokens and refresh tokens follow the system [Token policy](
|
|
94
|
+
The validity periods of OAuth access tokens and refresh tokens follow the system [Token policy](../security/token-policy/index.md) configuration.
|
|
95
95
|
|
|
96
96
|
- OAuth access tokens have the same validity period as system Tokens, with a default of **1 day**
|
|
97
97
|
- OAuth refresh tokens have the same validity period as system sessions, with a default of **7 days**
|
|
@@ -1,13 +1,20 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: "nb env add"
|
|
3
|
-
description: "nb env add command reference: save a NocoBase API URL and authentication method, then switch to
|
|
4
|
-
keywords: "nb env add,NocoBase CLI,add environment,API URL,authentication"
|
|
3
|
+
description: "nb env add command reference: save a NocoBase API URL and authentication method, then switch to that env."
|
|
4
|
+
keywords: "nb env add,NocoBase CLI,add environment,API Base URL,authentication"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# nb env add
|
|
8
8
|
|
|
9
9
|
Save a named NocoBase API endpoint and switch the CLI to use that env. When `oauth` authentication is selected, [`nb env auth`](./auth.md) is started automatically.
|
|
10
10
|
|
|
11
|
+
This command does two things:
|
|
12
|
+
|
|
13
|
+
- Save the env configuration
|
|
14
|
+
- Switch the current env to the newly added env
|
|
15
|
+
|
|
16
|
+
When session mode is enabled for the current shell or runtime, it updates the session `current env`. It also updates the global `last env` as the fallback for shells or runtimes without session mode.
|
|
17
|
+
|
|
11
18
|
## Usage
|
|
12
19
|
|
|
13
20
|
```bash
|
|
@@ -37,5 +44,6 @@ nb env add local --api-base-url http://localhost:13000/api --auth-type token --a
|
|
|
37
44
|
## Related Commands
|
|
38
45
|
|
|
39
46
|
- [`nb env auth`](./auth.md)
|
|
47
|
+
- [`nb env current`](./current.md)
|
|
40
48
|
- [`nb env update`](./update.md)
|
|
41
49
|
- [`nb env list`](./list.md)
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "nb env current"
|
|
3
|
+
description: "nb env current command reference: show the currently effective NocoBase CLI env."
|
|
4
|
+
keywords: "nb env current,NocoBase CLI,current env,session env"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# nb env current
|
|
8
|
+
|
|
9
|
+
Show the name of the currently effective env.
|
|
10
|
+
|
|
11
|
+
By default, this command first reads the session env for the current `NB_SESSION_ID`. If session mode is not enabled for the current shell or runtime, it falls back to the global `last env`.
|
|
12
|
+
|
|
13
|
+
## Usage
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
nb env current
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Examples
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
nb env current
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Related Commands
|
|
26
|
+
|
|
27
|
+
- [`nb env use`](./use.md)
|
|
28
|
+
- [`nb env status`](./status.md)
|
|
29
|
+
- [`nb session setup`](../session/setup.md)
|
|
@@ -1,13 +1,18 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: "nb env"
|
|
3
|
-
description: "nb env command reference: manage NocoBase CLI envs, including add,
|
|
4
|
-
keywords: "nb env,NocoBase CLI,environment management,env,authentication,OpenAPI"
|
|
3
|
+
description: "nb env command reference: manage NocoBase CLI envs, including add, inspect current env, check status, switch, authenticate, and remove."
|
|
4
|
+
keywords: "nb env,NocoBase CLI,environment management,env,current env,authentication,OpenAPI"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# nb env
|
|
8
8
|
|
|
9
9
|
Manage saved NocoBase CLI envs. An env stores API URL, authentication info, local app paths, database config, and runtime command cache.
|
|
10
10
|
|
|
11
|
+
In the current model, the CLI separates two concepts:
|
|
12
|
+
|
|
13
|
+
- `current env`: the env currently used by the active shell or agent runtime, isolated by `NB_SESSION_ID` when available
|
|
14
|
+
- `last env`: the globally last-used env, used as a fallback when session mode is not enabled
|
|
15
|
+
|
|
11
16
|
## Usage
|
|
12
17
|
|
|
13
18
|
```bash
|
|
@@ -18,9 +23,11 @@ nb env <command>
|
|
|
18
23
|
|
|
19
24
|
| Command | Description |
|
|
20
25
|
| --- | --- |
|
|
21
|
-
| [`nb env add`](./add.md) | Save a NocoBase API endpoint and switch to
|
|
26
|
+
| [`nb env add`](./add.md) | Save a NocoBase API endpoint and switch to that env |
|
|
27
|
+
| [`nb env current`](./current.md) | Show the currently effective env |
|
|
22
28
|
| [`nb env update`](./update.md) | Refresh OpenAPI Schema and runtime command cache from the app |
|
|
23
|
-
| [`nb env list`](./list.md) | List configured envs
|
|
29
|
+
| [`nb env list`](./list.md) | List configured envs |
|
|
30
|
+
| [`nb env status`](./status.md) | Show status for the current env, one env, or all envs |
|
|
24
31
|
| [`nb env info`](./info.md) | Show details for a single env |
|
|
25
32
|
| [`nb env remove`](./remove.md) | Remove env configuration |
|
|
26
33
|
| [`nb env auth`](./auth.md) | Run OAuth login for a saved env |
|
|
@@ -30,15 +37,26 @@ nb env <command>
|
|
|
30
37
|
|
|
31
38
|
```bash
|
|
32
39
|
nb env add app1 --api-base-url http://localhost:13000/api
|
|
40
|
+
nb env current
|
|
33
41
|
nb env list
|
|
42
|
+
nb env status
|
|
34
43
|
nb env info app1
|
|
35
44
|
nb env update app1
|
|
36
45
|
nb env use app1
|
|
37
46
|
nb env auth app1
|
|
38
47
|
```
|
|
39
48
|
|
|
49
|
+
## Session mode
|
|
50
|
+
|
|
51
|
+
Session mode is the default recommendation. It keeps `current env` isolated across different terminals, shells, and agent runtimes, so parallel work does not affect each other.
|
|
52
|
+
|
|
53
|
+
When session mode is not enabled, `nb env use` updates the global `last env`, and other sessions without isolation may also be affected.
|
|
54
|
+
|
|
55
|
+
See [`nb session setup`](../session/setup.md) to enable it.
|
|
56
|
+
|
|
40
57
|
## Related Commands
|
|
41
58
|
|
|
42
59
|
- [`nb init`](../init.md)
|
|
43
60
|
- [`nb api`](../api/index.md)
|
|
44
61
|
- [`nb app`](../app/index.md)
|
|
62
|
+
- [`nb session`](../session/index.md)
|
|
@@ -1,12 +1,14 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: "nb env list"
|
|
3
|
-
description: "nb env list command reference: list configured NocoBase CLI envs
|
|
4
|
-
keywords: "nb env list,NocoBase CLI,environment list,
|
|
3
|
+
description: "nb env list command reference: list configured NocoBase CLI envs."
|
|
4
|
+
keywords: "nb env list,NocoBase CLI,environment list,API Base URL"
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# nb env list
|
|
8
8
|
|
|
9
|
-
List all configured envs
|
|
9
|
+
List all configured envs.
|
|
10
|
+
|
|
11
|
+
This command only shows saved configuration. Use [`nb env status`](./status.md) when you want to check current runtime or API status.
|
|
10
12
|
|
|
11
13
|
## Usage
|
|
12
14
|
|
|
@@ -16,9 +18,11 @@ nb env list
|
|
|
16
18
|
|
|
17
19
|
## Output
|
|
18
20
|
|
|
19
|
-
The output table includes the current env marker, name, type,
|
|
21
|
+
The output table includes the current env marker, name, type, `API Base URL`, authentication type, and runtime version.
|
|
20
22
|
|
|
21
|
-
|
|
23
|
+
- `Current` marks the currently effective env with `*`
|
|
24
|
+
- `API Base URL` shows the saved raw API address
|
|
25
|
+
- `Runtime` shows cached runtime version information
|
|
22
26
|
|
|
23
27
|
## Examples
|
|
24
28
|
|
|
@@ -28,6 +32,7 @@ nb env list
|
|
|
28
32
|
|
|
29
33
|
## Related Commands
|
|
30
34
|
|
|
35
|
+
- [`nb env current`](./current.md)
|
|
36
|
+
- [`nb env status`](./status.md)
|
|
31
37
|
- [`nb env info`](./info.md)
|
|
32
38
|
- [`nb env use`](./use.md)
|
|
33
|
-
- [`nb db ps`](../db/ps.md)
|
|
@@ -8,6 +8,8 @@ keywords: "nb env remove,NocoBase CLI,delete environment,remove config"
|
|
|
8
8
|
|
|
9
9
|
Remove a configured env. This command only deletes CLI env configuration; use [`nb app down`](../app/down.md) to clean up local apps, containers, and storage.
|
|
10
10
|
|
|
11
|
+
If the removed env is also the current env, the CLI automatically selects a new current env from the remaining envs. If no envs remain, the current env is cleared.
|
|
12
|
+
|
|
11
13
|
## Usage
|
|
12
14
|
|
|
13
15
|
```bash
|
|
@@ -32,4 +34,5 @@ nb env remove staging -f
|
|
|
32
34
|
## Related Commands
|
|
33
35
|
|
|
34
36
|
- [`nb app down`](../app/down.md)
|
|
37
|
+
- [`nb env current`](./current.md)
|
|
35
38
|
- [`nb env list`](./list.md)
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "nb env status"
|
|
3
|
+
description: "nb env status command reference: show status for the current env, one env, or all envs."
|
|
4
|
+
keywords: "nb env status,NocoBase CLI,environment status,API Base URL"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# nb env status
|
|
8
|
+
|
|
9
|
+
Show env status. By default it inspects the current env. You can also inspect one named env, or use `--all` to inspect all envs.
|
|
10
|
+
|
|
11
|
+
This command prints a simplified status table with `Env`, `Status`, and `API Base URL`.
|
|
12
|
+
|
|
13
|
+
## Usage
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
nb env status [name] [flags]
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Parameters
|
|
20
|
+
|
|
21
|
+
| Parameter | Type | Description |
|
|
22
|
+
| --- | --- | --- |
|
|
23
|
+
| `[name]` | string | Env name to inspect; uses the current env if omitted |
|
|
24
|
+
| `--all` | boolean | Show status for all configured envs |
|
|
25
|
+
| `--json-output` | boolean | Output the result as JSON |
|
|
26
|
+
|
|
27
|
+
`[name]` and `--all` cannot be used together.
|
|
28
|
+
|
|
29
|
+
## Status values
|
|
30
|
+
|
|
31
|
+
`Status` is the result returned after the CLI checks the target env. Typical values include:
|
|
32
|
+
|
|
33
|
+
- `ok`: the env is reachable and authenticated
|
|
34
|
+
- `auth failed`: the API is reachable but authentication failed
|
|
35
|
+
- `unreachable`: the target address could not be reached
|
|
36
|
+
- `unconfigured`: the env configuration is incomplete
|
|
37
|
+
- `missing`: the managed app for this env no longer exists
|
|
38
|
+
|
|
39
|
+
## Examples
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
nb env status
|
|
43
|
+
nb env status app1
|
|
44
|
+
nb env status --all
|
|
45
|
+
nb env status --all --json-output
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## Related Commands
|
|
49
|
+
|
|
50
|
+
- [`nb env current`](./current.md)
|
|
51
|
+
- [`nb env list`](./list.md)
|
|
52
|
+
- [`nb env info`](./info.md)
|
|
@@ -8,6 +8,10 @@ keywords: "nb env use,NocoBase CLI,switch environment,current env"
|
|
|
8
8
|
|
|
9
9
|
Switch the current CLI env. Commands that omit `--env` will use this env by default afterward.
|
|
10
10
|
|
|
11
|
+
When session mode is enabled for the current shell or runtime, this change only affects the current session.
|
|
12
|
+
|
|
13
|
+
When session mode is not enabled, this falls back to updating the global `last env`. In that case, other terminals or agent runtimes without session isolation may also be affected.
|
|
14
|
+
|
|
11
15
|
## Usage
|
|
12
16
|
|
|
13
17
|
```bash
|
|
@@ -26,7 +30,13 @@ nb env use <name>
|
|
|
26
30
|
nb env use local
|
|
27
31
|
```
|
|
28
32
|
|
|
33
|
+
## Recommendation
|
|
34
|
+
|
|
35
|
+
The default recommendation is to run [`nb session setup`](../session/setup.md) once first. That makes `nb env use` behave more like `use dbname` in a database client: switch the current session context first, then run follow-up commands that depend on that env.
|
|
36
|
+
|
|
29
37
|
## Related Commands
|
|
30
38
|
|
|
39
|
+
- [`nb env current`](./current.md)
|
|
40
|
+
- [`nb env status`](./status.md)
|
|
31
41
|
- [`nb env list`](./list.md)
|
|
32
42
|
- [`nb env info`](./info.md)
|
|
@@ -35,11 +35,12 @@ The root command mainly displays help and dispatches execution to command groups
|
|
|
35
35
|
| [`nb app`](./app/index.md) | Manage NocoBase app runtimes: start, stop, restart, logs, and upgrades. |
|
|
36
36
|
| [`nb config`](./config/index.md) | Manage CLI configuration defaults. |
|
|
37
37
|
| [`nb db`](./db/index.md) | Manage the built-in database for the selected env. |
|
|
38
|
-
| [`nb env`](./env/index.md) | Manage NocoBase project environments, status, details, and command runtimes. |
|
|
38
|
+
| [`nb env`](./env/index.md) | Manage NocoBase project environments, current env, status, details, and command runtimes. |
|
|
39
39
|
| [`nb license`](./license/index.md) | Manage commercial licensing and licensed plugins. |
|
|
40
40
|
| [`nb plugin`](./plugin/index.md) | Manage plugins in the selected NocoBase env. |
|
|
41
41
|
| [`nb scaffold`](./scaffold/index.md) | Generate NocoBase plugin development scaffolds. |
|
|
42
42
|
| [`nb self`](./self/index.md) | Inspect or update the NocoBase CLI itself. |
|
|
43
|
+
| [`nb session`](./session/index.md) | Configure `NB_SESSION_ID` so current env is isolated per shell or agent runtime. |
|
|
43
44
|
| [`nb skills`](./skills/index.md) | Inspect or synchronize NocoBase AI coding skills for the current workspace. |
|
|
44
45
|
| [`nb source`](./source/index.md) | Work with the local NocoBase source project: download, develop, build, and test. |
|
|
45
46
|
|
|
@@ -93,6 +94,8 @@ Connect an existing app:
|
|
|
93
94
|
|
|
94
95
|
```bash
|
|
95
96
|
nb env add app1 --api-base-url http://localhost:13000/api
|
|
97
|
+
nb env current
|
|
98
|
+
nb env status
|
|
96
99
|
```
|
|
97
100
|
|
|
98
101
|
Start the app and refresh runtime commands:
|
|
@@ -130,6 +133,7 @@ The following environment variables affect CLI behavior:
|
|
|
130
133
|
| --- | --- |
|
|
131
134
|
| `NB_CLI_ROOT` | Root directory where the CLI stores `.nocobase` config and local app files. Defaults to the current user's home directory. |
|
|
132
135
|
| `NB_LOCALE` | Language for CLI prompts and the local setup UI. Supported values are `en-US` and `zh-CN`. |
|
|
136
|
+
| `NB_SESSION_ID` | Session ID for the current shell or agent runtime. When set, `nb env use` and `nb env current` are isolated per session. |
|
|
133
137
|
|
|
134
138
|
Example:
|
|
135
139
|
|
|
@@ -154,6 +158,14 @@ After setting `NB_CLI_ROOT=/your/workspace`, the config file path becomes:
|
|
|
154
158
|
|
|
155
159
|
The CLI also keeps compatibility with legacy project config under the current working directory.
|
|
156
160
|
|
|
161
|
+
Current env session cache is stored in:
|
|
162
|
+
|
|
163
|
+
```text
|
|
164
|
+
.nocobase/sessions/<NB_SESSION_ID>.json
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
The globally last-used env is stored in the `lastEnv` field in `config.json`. When `NB_SESSION_ID` is not set, the CLI falls back to that global value.
|
|
168
|
+
|
|
157
169
|
Runtime command cache is stored in:
|
|
158
170
|
|
|
159
171
|
```text
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "nb session id"
|
|
3
|
+
description: "nb session id command reference: show the current effective NB_SESSION_ID."
|
|
4
|
+
keywords: "nb session id,NocoBase CLI,NB_SESSION_ID,session id"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# nb session id
|
|
8
|
+
|
|
9
|
+
Show the current effective session id.
|
|
10
|
+
|
|
11
|
+
If no usable `NB_SESSION_ID` is available in the current shell or runtime, the command tells you to run [`nb session setup`](./setup.md) first, then open a new shell session or runtime.
|
|
12
|
+
|
|
13
|
+
## Usage
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
nb session id
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Examples
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
nb session id
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
## Related Commands
|
|
26
|
+
|
|
27
|
+
- [`nb session setup`](./setup.md)
|
|
28
|
+
- [`nb env current`](../env/current.md)
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "nb session"
|
|
3
|
+
description: "nb session command reference: configure and inspect NB_SESSION_ID so current env is isolated per shell or agent runtime."
|
|
4
|
+
keywords: "nb session,NocoBase CLI,NB_SESSION_ID,session mode"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# nb session
|
|
8
|
+
|
|
9
|
+
Manage session mode for `NB_SESSION_ID`.
|
|
10
|
+
|
|
11
|
+
After session mode is enabled, `nb env use` and `nb env current` use the current shell or agent runtime context first, instead of directly sharing a single global current env.
|
|
12
|
+
|
|
13
|
+
## Usage
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
nb session <command>
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Subcommands
|
|
20
|
+
|
|
21
|
+
| Command | Description |
|
|
22
|
+
| --- | --- |
|
|
23
|
+
| [`nb session setup`](./setup.md) | Install shell or runtime integration for `NB_SESSION_ID` |
|
|
24
|
+
| [`nb session id`](./id.md) | Show the current effective session id |
|
|
25
|
+
| [`nb session remove`](./remove.md) | Remove shell or runtime integration for `NB_SESSION_ID` |
|
|
26
|
+
|
|
27
|
+
## When you need it
|
|
28
|
+
|
|
29
|
+
The default recommendation is to run `nb session setup` once when you first start using the CLI. With it enabled:
|
|
30
|
+
|
|
31
|
+
- terminal 1 can use `env1`
|
|
32
|
+
- terminal 2 can use `env2` at the same time
|
|
33
|
+
- an agent runtime can keep its own current env too
|
|
34
|
+
|
|
35
|
+
Without session mode, different sessions fall back to sharing the global `last env`, which makes parallel work more likely to affect each other.
|
|
36
|
+
|
|
37
|
+
## Related Commands
|
|
38
|
+
|
|
39
|
+
- [`nb env current`](../env/current.md)
|
|
40
|
+
- [`nb env use`](../env/use.md)
|
|
41
|
+
- [`nb env status`](../env/status.md)
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "nb session remove"
|
|
3
|
+
description: "nb session remove command reference: remove shell or runtime integration for NB_SESSION_ID."
|
|
4
|
+
keywords: "nb session remove,NocoBase CLI,NB_SESSION_ID,remove session integration"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# nb session remove
|
|
8
|
+
|
|
9
|
+
Remove session integration for `NB_SESSION_ID`.
|
|
10
|
+
|
|
11
|
+
This command cleans up shell configuration previously written by [`nb session setup`](./setup.md). If opencode plugin integration is detected, it removes that integration too.
|
|
12
|
+
|
|
13
|
+
## Usage
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
nb session remove [flags]
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
## Parameters
|
|
20
|
+
|
|
21
|
+
| Parameter | Type | Description |
|
|
22
|
+
| --- | --- | --- |
|
|
23
|
+
| `--shell` | string | Target shell. Supported values: `bash`, `zsh`, `fish`, `powershell`, `cmd` |
|
|
24
|
+
|
|
25
|
+
## Examples
|
|
26
|
+
|
|
27
|
+
```bash
|
|
28
|
+
nb session remove
|
|
29
|
+
nb session remove --shell zsh
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Related Commands
|
|
33
|
+
|
|
34
|
+
- [`nb session setup`](./setup.md)
|
|
35
|
+
- [`nb session id`](./id.md)
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "nb session setup"
|
|
3
|
+
description: "nb session setup command reference: install shell or runtime integration for NB_SESSION_ID."
|
|
4
|
+
keywords: "nb session setup,NocoBase CLI,NB_SESSION_ID,shell integration"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# nb session setup
|
|
8
|
+
|
|
9
|
+
Install session integration for `NB_SESSION_ID`.
|
|
10
|
+
|
|
11
|
+
This command detects the current shell, or uses the shell you pass with `--shell`, and writes the matching initialization file so new shell sessions automatically get `NB_SESSION_ID`.
|
|
12
|
+
|
|
13
|
+
If opencode configuration is detected on the machine, it also writes the related plugin integration so the agent runtime can inject its own `NB_SESSION_ID`.
|
|
14
|
+
|
|
15
|
+
## Usage
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
nb session setup [flags]
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Parameters
|
|
22
|
+
|
|
23
|
+
| Parameter | Type | Description |
|
|
24
|
+
| --- | --- | --- |
|
|
25
|
+
| `--shell` | string | Target shell. Supported values: `bash`, `zsh`, `fish`, `powershell`, `cmd` |
|
|
26
|
+
|
|
27
|
+
## Notes
|
|
28
|
+
|
|
29
|
+
In most cases, you only need to run this once.
|
|
30
|
+
|
|
31
|
+
After it finishes, open a new shell session or reload your profile so `NB_SESSION_ID` is initialized automatically.
|
|
32
|
+
|
|
33
|
+
In agent runtimes such as Codex, if the runtime already injects a context variable such as `CODEX_THREAD_ID`, the CLI reuses that value first.
|
|
34
|
+
|
|
35
|
+
## Examples
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
nb session setup
|
|
39
|
+
nb session setup --shell zsh
|
|
40
|
+
nb session setup --shell powershell
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Related Commands
|
|
44
|
+
|
|
45
|
+
- [`nb session id`](./id.md)
|
|
46
|
+
- [`nb session remove`](./remove.md)
|
|
47
|
+
- [`nb env use`](../env/use.md)
|
|
@@ -79,7 +79,7 @@ For more details, see [Linkage Rules](/interface-builder/linkage-rule)
|
|
|
79
79
|
|
|
80
80
|
### Field template
|
|
81
81
|
|
|
82
|
-
Field templates let you reuse the field section configuration (selected fields, layout, and field settings) in Details blocks. See [Field template](
|
|
82
|
+
Field templates let you reuse the field section configuration (selected fields, layout, and field settings) in Details blocks. See [Field template](../../ui-templates.md).
|
|
83
83
|
|
|
84
84
|

|
|
85
85
|
|
|
@@ -73,7 +73,7 @@ The Form block supports two layout modes, which can be set via the `layout` attr
|
|
|
73
73
|
|
|
74
74
|
### Field Template
|
|
75
75
|
|
|
76
|
-
Field templates are used to reuse field area configurations in Form blocks. For details, see [Field Template](
|
|
76
|
+
Field templates are used to reuse field area configurations in Form blocks. For details, see [Field Template](../../ui-templates.md).
|
|
77
77
|
|
|
78
78
|

|
|
79
79
|
|
|
@@ -107,7 +107,7 @@ Key points:
|
|
|
107
107
|
|
|
108
108
|
- **`renderComponent()`** -- Renders the block UI, reading HTML content via `this.props.html`
|
|
109
109
|
- **`define()`** -- Sets the display name in the "Add Block" menu. `tExpr()` is used for deferred translation because `define()` executes at module load time, when i18n hasn't been initialized yet
|
|
110
|
-
- **`registerFlow()`** -- Adds a configuration panel. `uiSchema` defines the form using JSON Schema (syntax reference: [UI Schema](
|
|
110
|
+
- **`registerFlow()`** -- Adds a configuration panel. `uiSchema` defines the form using JSON Schema (syntax reference: [UI Schema](../../../flow-engine/ui-schema.md)), `handler` writes user-filled values to `ctx.model.props`, and `renderComponent()` can read them
|
|
111
111
|
|
|
112
112
|
## Step 3: Add Multilingual Files
|
|
113
113
|
|
|
@@ -194,7 +194,7 @@ Capabilities used in this example:
|
|
|
194
194
|
- [Writing Your First Plugin](../../write-your-first-plugin) -- Create a plugin skeleton from scratch
|
|
195
195
|
- [FlowEngine Overview](../flow-engine/index.md) -- FlowModel basic usage and registerFlow
|
|
196
196
|
- [FlowEngine -> Block Extension](../flow-engine/block) -- BlockModel, DataBlockModel, CollectionBlockModel
|
|
197
|
-
- [UI Schema](
|
|
197
|
+
- [UI Schema](../../../flow-engine/ui-schema.md) -- uiSchema syntax reference
|
|
198
198
|
- [Component vs FlowModel](../component-vs-flow-model) -- When to use FlowModel
|
|
199
199
|
- [Plugin](../plugin) -- Plugin entry point and load() lifecycle
|
|
200
200
|
- [i18n Internationalization](../component/i18n) -- Translation file conventions and tExpr usage
|
|
@@ -175,4 +175,4 @@ Activity records also appear in the calendar view on the Overview dashboard.
|
|
|
175
175
|
- [CRM User Guide](./index.md)
|
|
176
176
|
- [Lead Management](./guide-leads) — Leads automatically create customers and contacts upon conversion
|
|
177
177
|
- [Opportunity Management](./guide-opportunities) — Opportunities linked to customers
|
|
178
|
-
- [AI Employees](
|
|
178
|
+
- [AI Employees](../../../ai-employees/index.md)
|
|
@@ -201,10 +201,10 @@ Drill-through comes in two forms:
|
|
|
201
201
|
|
|
202
202
|
---
|
|
203
203
|
|
|
204
|
-
After understanding the system layout and dashboards, go back to the [User Guide](./
|
|
204
|
+
After understanding the system layout and dashboards, go back to the [User Guide](./index.md) for subsequent chapters.
|
|
205
205
|
|
|
206
206
|
## Related Pages
|
|
207
207
|
|
|
208
|
-
- [CRM User Guide](./
|
|
208
|
+
- [CRM User Guide](./index.md)
|
|
209
209
|
- [Solution Overview](../index)
|
|
210
210
|
- [Installation](../installation)
|
|
@@ -19,7 +19,7 @@ Compared to other no-code tools, NocoBase has a few core principles:
|
|
|
19
19
|
|
|
20
20
|
- **Data model driven**: Define your data structure first, then use [blocks](/interface-builder/blocks) to display data, then [actions](/interface-builder/actions) to process it — UI and data are fully decoupled
|
|
21
21
|
- **WYSIWYG**: Pages are your canvas. Click anywhere to edit, as intuitive as building a Notion page
|
|
22
|
-
- **Everything is a plugin**: All features are [plugins](/
|
|
22
|
+
- **Everything is a plugin**: All features are [plugins](../../plugins/index.mdx), similar to WordPress — install what you need
|
|
23
23
|
- **AI built into your workflow**: Built-in [AI employees](/ai-employees/quick-start) that can perform analysis, translation, data entry, and more
|
|
24
24
|
- **Open source + self-hosted**: Core code is fully open source, all data stays on your own server
|
|
25
25
|
|
|
@@ -181,7 +181,7 @@ This way, newly submitted tickets always appear at the top, making them easier t
|
|
|
181
181
|
Viewing a list isn't enough — we also need to click into tickets to see details and make edits.
|
|
182
182
|
|
|
183
183
|
1. In the actions column, click the second "+" icon.
|
|
184
|
-
2. Click to add actions: **View**, **[Edit](
|
|
184
|
+
2. Click to add actions: **View**, **[Edit](../../interface-builder/actions/types/edit.md)**, **[Delete](../../interface-builder/actions/types/delete.md)**.
|
|
185
185
|
3. Each row will now have "View", "Edit", and "Delete" buttons in the actions column.
|
|
186
186
|
|
|
187
187
|

|
|
@@ -211,7 +211,7 @@ Remember the "Categories" collection we created in Chapter 2? It's a **tree tabl
|
|
|
211
211
|
|
|
212
212
|
Once enabled, the table will display categories in an indented hierarchy showing parent-child relationships, instead of listing all records flat.
|
|
213
213
|
|
|
214
|
-
3. Check the fields you want to display (e.g., Name, Description), and configure row actions ([Add new](
|
|
214
|
+
3. Check the fields you want to display (e.g., Name, Description), and configure row actions ([Add new](../../interface-builder/actions/types/add-new.md), Edit, Delete).
|
|
215
215
|
4. **Layout tip**: Put "Name" in the first column and "Actions" in the second. The categories table doesn't have many fields, so a two-column layout is more compact and user-friendly.
|
|
216
216
|
|
|
217
217
|
[Screenshot: Categories tree table configured]
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Chapter 4: Forms & Details — Input, Display, All in One
|
|
2
2
|
|
|
3
|
-
In the last chapter, we built the ticket list and used a quick form to enter test data. In this chapter, we'll **refine the form experience** — optimize [Form block](/interface-builder/blocks/data-blocks/form) field layouts, add [Details blocks](/interface-builder/blocks/data-blocks/details), configure [linkage rules](
|
|
3
|
+
In the last chapter, we built the ticket list and used a quick form to enter test data. In this chapter, we'll **refine the form experience** — optimize [Form block](/interface-builder/blocks/data-blocks/form) field layouts, add [Details blocks](/interface-builder/blocks/data-blocks/details), configure [linkage rules](../../interface-builder/linkage-rule.md), and use [change history](https://docs.nocobase.com/record-history/) to track every modification.
|
|
4
4
|
|
|
5
5
|
:::tip
|
|
6
6
|
Section 4.4 "Change History" requires the [Professional edition](https://www.nocobase.com/en/commercial). Skipping it won't affect later chapters.
|
|
@@ -15,7 +15,7 @@ In the last chapter, we quickly created a working "Add new" form. Now let's refi
|
|
|
15
15
|
1. Make sure you're in [UI Editor](/get-started/how-nocobase-works) mode (top-right toggle is on).
|
|
16
16
|
2. Go to the "All Tickets" page, and click **"[Actions](/interface-builder/actions)"** above the Table block.
|
|
17
17
|
3. Check the **"Add new"** action button.
|
|
18
|
-
4. An "Add new" button will appear above the table. Clicking it opens a [popup](
|
|
18
|
+
4. An "Add new" button will appear above the table. Clicking it opens a [popup](../../interface-builder/actions/types/pop-up.md).
|
|
19
19
|
|
|
20
20
|

|
|
21
21
|
|
|
@@ -268,7 +268,7 @@ In this chapter, we completed the full data lifecycle:
|
|
|
268
268
|
- **Form** — Users can submit new tickets with default values and validation
|
|
269
269
|
- **Linkage rules** — Urgent tickets automatically require a description
|
|
270
270
|
- **Details block** — Clearly displays a ticket's complete information
|
|
271
|
-
- **[Change history](
|
|
271
|
+
- **[Change history](../../record-history/index.md)** — Automatically tracks every modification for worry-free auditing (commercial plugin, optional)
|
|
272
272
|
|
|
273
273
|
From "visible" to "enterable" to "traceable" — our ticket system now has basic usability.
|
|
274
274
|
|
|
@@ -276,4 +276,4 @@ From "visible" to "enterable" to "traceable" — our ticket system now has basic
|
|
|
276
276
|
|
|
277
277
|
- [Form Block](/interface-builder/blocks/data-blocks/form) — Form block configuration guide
|
|
278
278
|
- [Details Block](/interface-builder/blocks/data-blocks/details) — Details block setup
|
|
279
|
-
- [Linkage Rules](
|
|
279
|
+
- [Linkage Rules](../../interface-builder/linkage-rule.md) — Field linkage configuration
|
|
@@ -34,7 +34,7 @@ NocoBase offers several trigger types, which you select when creating a workflow
|
|
|
34
34
|
|---------|-------------|-----------------|
|
|
35
35
|
| **[Collection event](/workflow/triggers/collection)** | Fires when a record is created, updated, or deleted | New ticket notification, status change logging |
|
|
36
36
|
| **[Schedule](/workflow/triggers/schedule)** | Fires on a Cron expression or fixed time | Daily reports, periodic data cleanup |
|
|
37
|
-
| **[Post-action event](
|
|
37
|
+
| **[Post-action event](../../workflow/triggers/post-action.md)** | Fires after a user performs a UI action | Send notification after form submission |
|
|
38
38
|
| **Approval** | Initiates an approval flow with multi-level support | Leave requests, purchase approvals |
|
|
39
39
|
| **Custom action** | Bound to a custom button, fires on click | One-click archiving, batch operations |
|
|
40
40
|
| **Pre-action event** | Intercepts a user action synchronously before it completes | Pre-submit validation, auto-fill fields |
|
|
@@ -8,7 +8,7 @@ pkg: '@nocobase/plugin-workflow-javascript'
|
|
|
8
8
|
|
|
9
9
|
The JavaScript Script node allows users to execute a custom server-side JavaScript script within a workflow. The script can use variables from upstream in the workflow as parameters, and its return value can be provided to downstream nodes.
|
|
10
10
|
|
|
11
|
-
The script runs in a worker thread on the NocoBase application's server. By default, it uses a secure sandbox (
|
|
11
|
+
The script runs in a worker thread on the NocoBase application's server. By default, it uses a secure sandbox (QuickJS, powered by WebAssembly) that does not support `require` or Node.js built-in APIs. For details, see [Execution Engine](#execution-engine) and [Feature List](#feature-list).
|
|
12
12
|
|
|
13
13
|
## Create Node
|
|
14
14
|
|
|
@@ -50,7 +50,7 @@ The JavaScript script node supports two execution engines, automatically selecte
|
|
|
50
50
|
|
|
51
51
|
### Safe Mode (Default)
|
|
52
52
|
|
|
53
|
-
When `WORKFLOW_SCRIPT_MODULES` is **not configured**, scripts run using the [
|
|
53
|
+
When `WORKFLOW_SCRIPT_MODULES` is **not configured**, scripts run using the [QuickJS](https://bellard.org/quickjs/) engine compiled to WebAssembly. This engine executes code in an isolated JavaScript runtime with the following characteristics:
|
|
54
54
|
|
|
55
55
|
- **Does not support** `require` — no modules can be imported
|
|
56
56
|
- **Does not support** Node.js built-in APIs (such as `process`, `Buffer`, `global`, etc.)
|