@nocobase/plugin-ai 2.3.0-alpha.1 → 2.3.0-beta.2

package/dist/ai/docs/nocobase/runjs/context/ai.md

@@ -1,23 +1,51 @@
 ---
 title: "ctx.ai"
-description: "Use ctx.ai in RunJS to trigger AI employee tasks, either with inline task content or with tasks configured on an AI employee action."
-keywords: "ctx.ai,AI employee,triggerTask,triggerModelTask,RunJS,NocoBase"
+description: "Use ctx.ai in RunJS to trigger AI employee tasks in the global conversation or a specified AI Chat Box, either with inline task content or with tasks configured on an AI employee action."
+keywords: "ctx.ai,AI employee,uploadFile,attachments,triggerTask,triggerModelTask,onResponseLoadingChange,chatBoxUid,AI Chat Box,RunJS,NocoBase"
 ---
 
 # ctx.ai
 
 Use `ctx.ai` in RunJS to trigger **AI employee tasks**. It works well in JSBlock, JSAction, and other interactions where a button, form, or business flow needs to hand work to a specific AI employee.
 
-`ctx.ai` only triggers tasks. It does not return the execution result of the AI employee task. After the call, the task enters the AI employee conversation flow, and the result is handled by the AI employee session.
+`ctx.ai` uploads AI task attachments and triggers tasks. File uploads can be awaited, but task triggering does not return the execution result of the AI employee task. After the call, the task enters the AI employee conversation flow, and the result is handled by the AI employee session.
 
 :::warning Note
 
-`ctx.ai` is provided by the AI plugin. If the AI plugin is not enabled, or the current RunJS environment has not loaded the corresponding client capability, `ctx.ai` may not exist. You can check `ctx.ai?.triggerTask` or `ctx.ai?.triggerModelTask` before calling it.
+`ctx.ai` is provided by the AI plugin. If the AI plugin is not enabled, or the current RunJS environment has not loaded the corresponding client capability, `ctx.ai` may not exist. You can check `ctx.ai?.uploadFile`, `ctx.ai?.triggerTask`, or `ctx.ai?.triggerModelTask` before calling it.
 
 :::
 
 ## Methods
 
+### ctx.ai.uploadFile()
+
+Upload one file and return an attachment object that can be passed directly to an AI employee task.
+
+```ts
+const attachment = await ctx.ai.uploadFile(file, options);
+```
+
+| Parameter | Type | Description |
+|------|------|------|
+| `file` | `File` | Browser file object to upload. |
+| `options.onProgress` | `(percent: number) => void` | Upload progress callback. `percent` ranges from `0` to `100`. |
+| `options.signal` | `AbortSignal` | Signal used to cancel the upload. |
+
+The upload uses the file storage configured by the AI plugin and creates a record in `aiFiles`. The returned object includes fields such as `id`, `filename`, `url`, and `source`:
+
+```ts
+const attachment = await ctx.ai.uploadFile(file, {
+  onProgress(percent) {
+    console.log('upload progress', percent);
+  },
+});
+
+// attachment can be placed directly in message.attachments
+```
+
+The Promise is rejected when the upload fails. Removing an attachment from the local UI does not delete the record already created in `aiFiles`, matching the behavior of the default AI chat window.
+
 ### ctx.ai.triggerTask()
 
 Trigger an AI employee task directly.
@@ -30,8 +58,10 @@ ctx.ai.triggerTask(options: TriggerTaskOptions): void
 |------|------|------|
 | `aiEmployee` | `string \| AIEmployee` | AI employee. When a string is passed, NocoBase matches `AIEmployee.username` exactly, and the AI employee must be accessible to the current user. |
 | `tasks` | `Task[]` | Tasks to trigger. |
+| `chatBoxUid` | `string` | FlowModel uid of the AI Chat Box block that should receive the task. |
 | `open` | `boolean` | Whether to open the AI employee conversation panel. |
 | `auto` | `boolean` | Whether to use the auto-trigger semantics of an AI employee action. |
+| `onResponseLoadingChange` | `(loading: boolean) => void` | Model response loading callback. It only runs when this task is sent automatically. |
 
 Common `Task` fields:
 
@@ -40,12 +70,160 @@ Common `Task` fields:
 | `title` | `string` | Task title. |
 | `message.system` | `string` | System message, used to constrain the AI employee's role and output requirements. |
 | `message.user` | `string` | User message, which is the main instruction for this task. |
+| `message.attachments` | `Attachment[]` | Attachments used by the task, usually returned by `ctx.ai.uploadFile()`. |
 | `message.workContext` | `ContextItem[]` | Page block context used by the task. |
 | `autoSend` | `boolean` | Whether to send the task message automatically. |
 | `webSearch` | `boolean` | Whether Web search is allowed for this task. |
 | `model` | `{ llmService: string; model: string } \| null` | Model used by this task. |
 | `skillSettings` | `SkillSettings` | Skills and tools available to this task. |
 
+### Track the Response Loading State
+
+Pass `onResponseLoadingChange` in the top-level options to track the model response loading state for this task. The callback receives `true` when NocoBase starts waiting for the model response, and `false` when the response completes, is canceled, or fails. If the React component has declared `setResponseLoading` with `useState`, you can write:
+
+```tsx
+ctx.ai.triggerTask({
+  aiEmployee: 'nathan',
+  open: true,
+  tasks: [
+    {
+      title: ctx.t('Review current page'),
+      message: {
+        user: 'Review the current page and summarize the main risks.',
+      },
+      autoSend: true,
+    },
+  ],
+  onResponseLoadingChange(loading) {
+    setResponseLoading(loading);
+  },
+});
+```
+
+`onResponseLoadingChange` only tracks the model response started directly by this `triggerTask()` call. With `autoSend: false`, the task is placed in the chat draft and the callback does not run. If the user sends the draft later, that manual send does not reuse this callback.
+
+In a React component inside a JS block, this state update rerenders the component while it remains mounted.
+
+### Target an AI Chat Box
+
+Set `chatBoxUid` on the top-level `triggerTask()` options to trigger the task in a mounted AI Chat Box block instead of the global AI employee dialog.
+
+```ts
+ctx.ai.triggerTask({
+  aiEmployee: 'nathan',
+  chatBoxUid: 'AI_CHAT_BOX_BLOCK_UID',
+  open: true,
+  tasks: [
+    {
+      title: ctx.t('Review current page'),
+      message: {
+        user: 'Review the current page and summarize the main risks.',
+      },
+    },
+  ],
+});
+```
+
+The uid must belong to the outer AI Chat Box block currently mounted on the page. Do not put this routing value inside `tasks`. If the target block cannot be found, NocoBase reports an error and does not fall back to the global dialog. When `chatBoxUid` is omitted, the task uses the global AI employee dialog.
+
+### Upload and Send Attachments in JSBlock
+
+The following example renders file upload, task instructions, and a send button in JSBlock. Uploaded files are passed to the AI employee through `message.attachments`:
+
+```tsx
+if (!ctx.ai?.uploadFile || !ctx.ai?.triggerTask) {
+  ctx.message.error(ctx.t('AI employee task API is not available.'));
+  return;
+}
+
+const { React } = ctx.libs;
+const { useState } = React;
+const { Button, Card, Input, Space, Upload } = ctx.libs.antd;
+const { InboxOutlined, SendOutlined } = ctx.libs.antdIcons;
+
+const AttachmentTask = () => {
+  const [prompt, setPrompt] = useState('');
+  const [fileList, setFileList] = useState([]);
+
+  const uploadAttachment = async ({ file, onError, onProgress, onSuccess }) => {
+    try {
+      const attachment = await ctx.ai.uploadFile(file, {
+        onProgress(percent) {
+          onProgress?.({ percent });
+        },
+      });
+      onSuccess?.(attachment);
+    } catch (error) {
+      onError?.(error instanceof Error ? error : new Error(ctx.t('File upload failed')));
+    }
+  };
+
+  const sendTask = () => {
+    const attachments = fileList
+      .filter((file) => file.status === 'done' && file.response)
+      .map((file) => file.response);
+
+    if (!prompt.trim()) {
+      ctx.message.warning(ctx.t('Enter task instructions'));
+      return;
+    }
+
+    ctx.ai.triggerTask({
+      aiEmployee: 'viz',
+      open: true,
+      tasks: [
+        {
+          title: ctx.t('Analyze uploaded files'),
+          message: {
+            user: prompt.trim(),
+            attachments,
+          },
+          autoSend: true,
+        },
+      ],
+    });
+    setPrompt('');
+    setFileList([]);
+  };
+
+  const uploading = fileList.some((file) => file.status === 'uploading');
+
+  return (
+    <Card title={ctx.t('AI file analysis')}>
+      <Space direction="vertical" size="middle" style={{ width: '100%' }}>
+        <Upload.Dragger
+          multiple
+          fileList={fileList}
+          customRequest={uploadAttachment}
+          onChange={({ fileList: nextFileList }) => setFileList(nextFileList)}
+        >
+          <p className="ant-upload-drag-icon"><InboxOutlined /></p>
+          <p>{ctx.t('Click or drag files here to upload')}</p>
+        </Upload.Dragger>
+        <Input.TextArea
+          value={prompt}
+          onChange={(event) => setPrompt(event.target.value)}
+          placeholder={ctx.t('Describe the task for the AI employee')}
+          autoSize={{ minRows: 3, maxRows: 8 }}
+        />
+        <Button
+          type="primary"
+          icon={<SendOutlined />}
+          disabled={uploading || !prompt.trim()}
+          onClick={sendTask}
+        >
+          {ctx.t('Send to AI')}
+        </Button>
+      </Space>
+    </Card>
+  );
+};
+
+ctx.render(<AttachmentTask />);
+```
+
+With `autoSend: false`, the attachments and task instructions are placed in the AI chat draft instead of being sent immediately.
+
 ### Add Page Block Context
 
 `message.workContext` currently passes page blocks. Put the FlowModel uid of the target page block into it:
@@ -163,9 +341,15 @@ ctx.ai.triggerModelTask(uid: string, taskIndex: number, options?: TriggerModelTa
 | `taskIndex` | `number` | Task index, starting from `0`. |
 | `options.open` | `boolean` | Whether to open the AI employee conversation panel. |
 | `options.auto` | `boolean` | Whether to use the auto-trigger semantics of an AI employee action. |
+| `options.attachments` | `Attachment[]` | Attachments dynamically appended to the configured task. |
+| `options.onResponseLoadingChange` | `(loading: boolean) => void` | Model response loading callback. It only runs when the configured task is sent automatically. |
 
 This method reads the AI employee and task configuration from the target model. It is useful when the task has already been configured on an AI employee action on the page, and RunJS only needs to trigger it.
 
+The public `triggerModelTask()` options do not accept `chatBoxUid`. To target an AI Chat Box, configure `chatBoxUid` on the preset task of the AI employee action. `triggerModelTask()` continues to reuse that preset value.
+
+`options.onResponseLoadingChange` behaves the same as the option on `triggerTask()`. Whether it runs depends on the configured task's `autoSend` value. It does not run when that task uses `autoSend: false`.
+
 ```ts
 if (!ctx.ai?.triggerModelTask) {
   ctx.message.error(ctx.t('AI employee task API is not available.'));
@@ -176,6 +360,7 @@ const weeklyReviewActionUid = 'AI_EMPLOYEE_ACTION_MODEL_UID';
 
 ctx.ai.triggerModelTask(weeklyReviewActionUid, 0, {
   open: true,
+  attachments,
 });
 
 ctx.message.success(ctx.t('Configured AI employee task triggered.'));
@@ -195,9 +380,14 @@ If the target model does not exist, has no AI employee configured, or the specif
 ## Notes
 
 - `triggerTask()` and `triggerModelTask()` are fire-and-forget. They do not return the execution result of the AI employee task.
+- `uploadFile()` returns a Promise. Wait for the upload to finish before triggering a task that uses the attachment.
 - `aiEmployee` strings only match `AIEmployee.username` exactly. They do not match nicknames, job titles, or translated names.
 - `triggerModelTask()` uses a `0`-based `taskIndex`.
 - `triggerModelTask()` reads task configuration from the target AI employee action model. If the task needs work context, configure `message.workContext` on that task.
+- Top-level `triggerTask().chatBoxUid` must reference an AI Chat Box block currently mounted on the page.
+- `triggerModelTask()` keeps using `chatBoxUid` configured on its preset task.
+- Dynamic `triggerModelTask()` attachments are appended to the preset task's existing `message.attachments` without changing the saved task configuration.
+- `onResponseLoadingChange` only tracks a model response automatically sent by the current call. It does not track a message the user sends manually later.
 
 ## Related
 

package/dist/ai/docs/nocobase/users-permissions/sync/index.md

@@ -8,6 +8,13 @@ pkg: '@nocobase/plugin-user-data-sync'
 
 This feature allows you to register and manage user data synchronization sources. By default, an HTTP API is provided, but additional data sources can be supported through plugins. It supports syncing data to the **Users** and **Departments** collections by default, with the possibility to extend synchronization to other target resources using plugins.
 
+## Available data sources
+
+- [DingTalk](./sources/dingtalk.md) — Synchronize DingTalk users and departments, with incremental updates through HTTP callbacks or Stream mode.
+- [LDAP](./sources/ldap.md) — Synchronize LDAP users and optional organizational units by reusing an LDAP authenticator.
+- [WeCom](./sources/wecom.md) — Synchronize users and departments from WeCom.
+- [HTTP API](./sources/api.md) — Push user and department data through the synchronization API.
+
 ## Data Source Management and Synchronization
 
 
@@ -51,4 +58,4 @@ For failed synchronization tasks, you can click **Retry**.
 In case of synchronization failures, you can troubleshoot the issue through system logs. Additionally, raw synchronization records are stored in the `user-data-sync` directory under the application logs folder.
 
 
-![](https://static-docs.nocobase.com/202412041205655.png)
+![](https://static-docs.nocobase.com/202412041205655.png)

package/dist/ai/docs/nocobase/users-permissions/sync/sources/dingtalk.md

@@ -0,0 +1,138 @@
+---
+pkg: '@nocobase/plugin-auth-dingtalk'
+title: "Synchronize User Data from DingTalk"
+description: "Synchronize DingTalk users and departments to NocoBase and receive incremental changes through HTTP callbacks or Stream mode."
+keywords: "DingTalk,user synchronization,department synchronization,Stream mode,event subscription,NocoBase"
+---
+
+# Synchronize User Data from DingTalk
+
+<PluginInfo commercial="true" name="auth-dingtalk"></PluginInfo>
+
+## Introduction
+
+The **DingTalk** plugin synchronizes users and departments from a DingTalk organization to NocoBase. It supports full synchronization on demand and incremental updates through either an HTTP callback or a Stream connection.
+
+## Before you begin
+
+1. Install and enable the **DingTalk** and **User Data Synchronization** plugins.
+2. Create an internal application in the DingTalk developer console.
+3. Grant the contact permissions and configure the data permission scope described below.
+4. Copy the application's Client ID and Client Secret. See [Authentication: DingTalk](/auth-verification/auth-dingtalk/) for the credential setup.
+
+## Configure contact permissions and the data permission scope
+
+Open **Permission Management** for the application in the DingTalk developer console and grant the following contact permissions.
+
+| Permission | Identifier | Required | Purpose |
+| --- | --- | --- | --- |
+| Read department information | `qyapi_get_department_list` | Yes | Read the department list, names, and hierarchy. |
+| Read department members | `qyapi_get_department_member` | Yes | Read the member list of each department. |
+| Read member information | `qyapi_get_member` | Yes | Read member details and department memberships. |
+| Employee mobile number information | `fieldMobile` | When using mobile numbers | Synchronize mobile numbers. This permission is required when **User unique identifier field** is `mobile`. |
+| Email and other personal information | `fieldEmail` | No | Grant this permission when user email addresses need to be synchronized. |
+
+After granting the permissions, configure the application's **Data Permission Scope** (also called **Contact Permission Scope** or **Visibility Range** in some console versions) to include the departments and employees that may be synchronized. Select all employees for a full organization synchronization. If only selected departments or employees are included, NocoBase synchronizes only those entries.
+
+:::warning
+API permissions determine which fields the application can read, while the data permission scope determines which departments and employees it can read. Both must be configured. Event subscriptions do not replace contact read permissions: after receiving an event, NocoBase still calls DingTalk APIs to retrieve the latest user or department information.
+:::
+
+If the same DingTalk application is also used for sign-in, grant the personal-information permissions described in [Authentication: DingTalk](/auth-verification/auth-dingtalk/). Those sign-in permissions are not required solely for user data synchronization.
+
+## Add a DingTalk synchronization source
+
+Go to **Users & Permissions > Synchronize**, click **Add new**, and select **DingTalk** as the type.
+
+Configure the following fields:
+
+| Field | Description |
+| --- | --- |
+| Source name | A unique name for this synchronization source. |
+| Enabled | Starts event reception for this source and enables synchronization tasks. |
+| Client ID | The Client ID of the DingTalk internal application. Environment variables and secrets are supported. |
+| Client Secret | The Client Secret of the DingTalk internal application. Environment variables and secrets are supported. |
+| User unique identifier field | Select `mobile` or `unionId`. Keep the selected field stable after the first synchronization. Users without a value for the selected field are skipped. |
+| Event receiving mode | Select **HTTP callback** or **Stream mode** for incremental user and department changes. |
+
+Save and enable the source, then click **Sync** to complete the initial full synchronization before relying on incremental events.
+
+## Choose an event receiving mode
+
+### Stream mode
+
+Stream mode establishes an outbound persistent connection from the NocoBase server to DingTalk. It does not require a public callback URL, Token, or EncodingAESKey.
+
+1. In the DingTalk developer console, open the application's event subscription settings and select **Stream mode**.
+2. Subscribe to the user and department change events required by the application.
+3. In NocoBase, select **Stream mode**, save the source, and enable it.
+
+The Stream client starts when the source is enabled. Updating, disabling, or deleting the source refreshes or closes the corresponding connection.
+
+:::info
+The NocoBase server must be able to establish outbound connections to DingTalk. A reverse proxy or public inbound callback endpoint is not required for Stream mode.
+:::
+
+### HTTP callback
+
+HTTP callback mode receives DingTalk events through a NocoBase callback URL.
+
+1. Select **HTTP callback** in NocoBase.
+2. Enter the Token and EncodingAESKey configured for the DingTalk event subscription.
+3. Save the source and copy the generated **Event callback URL**.
+4. Configure that URL in the DingTalk developer console and subscribe to the required user and department events.
+
+The callback URL must be reachable by DingTalk. In a production environment, expose it through HTTPS and make sure the reverse proxy forwards the request path unchanged.
+
+## Supported incremental events
+
+Both event receiving modes handle the following DingTalk events:
+
+| Event | Result in NocoBase |
+| --- | --- |
+| `user_add_org` | Create or update the user. |
+| `user_modify_org` | Update the user. |
+| `user_leave_org` | Delete the synchronized user. |
+| `org_dept_create` | Create or update the department. |
+| `org_dept_modify` | Update the department and synchronize its users. |
+| `org_dept_remove` | Delete the synchronized department. |
+
+## Synchronized fields
+
+### Department fields
+
+| DingTalk field | NocoBase field or purpose |
+| --- | --- |
+| `dept_id` | Source-unique department identifier. |
+| `name` | Department name. |
+| `parent_id` | Parent department used to build the department hierarchy. If the parent is outside the data permission scope, the department is synchronized as a root department. |
+
+### User fields
+
+| DingTalk field | NocoBase field or purpose |
+| --- | --- |
+| `mobile` or `unionid` | Generates the source-unique user identifier and username according to **User unique identifier field**. A user without the selected field is skipped. |
+| `name` | User nickname. |
+| `mobile` | Phone number. Requires the **Employee mobile number information** permission. |
+| `email`, falling back to `org_email` | Email address. Requires the **Email and other personal information** permission. |
+| `dept_id_list` | Department memberships. Only departments within the data permission scope are retained. |
+| `dept_order_list` | Primary department. |
+| `leader_in_dept` | Whether the user is an owner of the corresponding department. |
+
+### Department owners
+
+DingTalk uses `leader_in_dept` in the user details to indicate whether the user is an owner of each department they belong to. NocoBase synchronizes this flag separately for each department: the same user can own multiple departments, and an owned department does not have to be the user's primary department. Only departments within the data permission scope are included.
+
+When an owner flag is removed in DingTalk, the corresponding owner flag in NocoBase is removed by the next synchronization. Owner status changed manually in NocoBase may be overwritten by DingTalk data during the next synchronization.
+
+Full and incremental synchronization use the same field mapping. Other DingTalk user fields, such as avatar, job title, and employee number, are not currently synchronized.
+
+## Troubleshooting
+
+- If synchronization returns no data or an entire department is missing, verify the three required contact read permissions and confirm that the department is included in the data permission scope.
+- If a user is present but their mobile number or email address is empty, verify the **Employee mobile number information** or **Email and other personal information** permission respectively.
+- If DingTalk reports that a department or employee is outside the permission scope, expand the application's data permission scope instead of only resubscribing to events.
+- If users are skipped, verify that they have a value for the configured unique identifier field.
+- For Stream mode, check the application logs for `Dingtalk stream client starting`, `Dingtalk stream client started`, or connection errors.
+- For HTTP callback mode, verify that the callback URL is publicly reachable and that Token and EncodingAESKey match the DingTalk configuration.
+- Run a manual full synchronization after changing the application's permissions or visibility range.

package/dist/ai/docs/nocobase/users-permissions/sync/sources/ldap.md

@@ -0,0 +1,87 @@
+---
+pkg: '@nocobase/plugin-auth-ldap'
+title: "Synchronize User Data from LDAP"
+description: "Synchronize LDAP users and departments to NocoBase by reusing an existing LDAP authenticator."
+keywords: "LDAP,user synchronization,department synchronization,Bind DN,Search DN,NocoBase"
+---
+
+# Synchronize User Data from LDAP
+
+<PluginInfo commercial="true" name="auth-ldap"></PluginInfo>
+
+## Introduction
+
+The **Auth: LDAP** plugin can use an existing LDAP authenticator as a user data synchronization source. The synchronization source reuses the authenticator's LDAP connection, Bind DN, Search DN, search scope, and attribute mappings, then writes the resulting users and optional department hierarchy to NocoBase.
+
+## Before you begin
+
+1. Install and enable the **Auth: LDAP** and **User Data Synchronization** plugins.
+2. Create and verify an LDAP authenticator. See [Authentication: LDAP](/auth-verification/auth-ldap/).
+3. Make sure the authenticator's attribute mappings include the fields needed by NocoBase, such as username or email, nickname, and phone number.
+
+## Add an LDAP synchronization source
+
+Go to **Users & Permissions > Synchronize**, click **Add new**, and select **LDAP** as the type.
+
+Configure the following fields:
+
+| Field | Description |
+| --- | --- |
+| Source name | A unique name for this synchronization source. |
+| Enabled | Enables manual synchronization and LDAP synchronization tasks for this source. |
+| LDAP authenticator | The existing LDAP authenticator whose connection and attribute mappings will be reused. |
+| Sync filter | The LDAP filter used to find users during synchronization. The default is `(&(objectCategory=person)(objectClass=user))`. Adjust it to match your directory schema. |
+| Size limit | Optional maximum number of entries returned by an LDAP search. Leave it empty to use the LDAP server's default limit. |
+| Page size | Optional page size for paged LDAP searches. Use this when the directory contains more entries than a single query can return. |
+| Sync departments | Also synchronizes the LDAP organizational hierarchy to NocoBase departments. |
+| Department search DN | Required when department synchronization is enabled. Specify the DN that contains the organizational units to synchronize, for example `ou=departments,dc=example,dc=com`. |
+
+:::info
+The synchronization source uses the selected authenticator's Bind DN and Bind password to search LDAP. It does not store a second copy of the LDAP connection credentials.
+:::
+
+## Synchronize users
+
+Save and enable the source, then click **Sync** to start a full synchronization. Open **Task** to review the result and retry a failed task.
+
+User matching follows the field selected in the LDAP authenticator's **Use this field to bind the user** setting. Keep that setting and the authenticator's attribute mappings stable after the first synchronization to avoid creating duplicate users.
+
+## Synchronize departments
+
+Enable **Sync departments** and enter a **Department search DN** when the LDAP directory contains a hierarchy that should be represented in NocoBase.
+
+The plugin searches organizational units below that DN, preserves their parent-child relationships, and associates users with departments based on their distinguished names. The configured Department search DN must cover the organizational units referenced by the users you expect to synchronize.
+
+## Synchronized fields
+
+### User fields
+
+User fields reuse the selected LDAP authenticator's **Attribute mapping**:
+
+| LDAP attribute or setting | NocoBase field or purpose |
+| --- | --- |
+| Login account attribute | Used as the source-unique user identifier and written to the username or email selected by the authenticator's **Use this field to bind the user** setting. This attribute is usually inferred from `{{account}}` in the authenticator's search filter, such as `uid`, `sAMAccountName`, or `mail`. A user without this attribute is skipped. |
+| Attribute mapped to `username` | Username. |
+| Attribute mapped to `nickname` | User nickname. |
+| Attribute mapped to `email` | Email address. |
+| Attribute mapped to `phone` | Phone number. |
+| `distinguishedName`, falling back to the entry DN | Finds the nearest synchronized department in the DN path and sets it as the user's primary department. This applies only when department synchronization is enabled. |
+
+For a multi-valued LDAP attribute, only the first value is currently synchronized. Other user attributes that are not included in the authenticator's attribute mapping are not synchronized.
+
+### Department fields
+
+| LDAP attribute or structure | NocoBase field or purpose |
+| --- | --- |
+| `objectGUID` | Source-unique department identifier. An organizational unit without this attribute is skipped. |
+| `ou`, `cn`, `name` | The first non-empty value in this order becomes the department name. An organizational unit without a name is skipped. |
+| `distinguishedName`, falling back to the entry DN | Identifies the current department and its parent to build the department hierarchy. |
+
+Department synchronization searches for `organizationalUnit` and `container` objects by default. It does not currently synchronize multiple user departments from attributes such as `memberOf`, or department owners.
+
+## Troubleshooting
+
+- If no users are returned, verify the authenticator's Search DN, search scope, Bind DN permissions, and the synchronization filter.
+- If the result is truncated, configure a page size and verify the LDAP server's size limits.
+- If departments are missing, verify that department synchronization is enabled and the Department search DN covers the required organizational units.
+- Review the synchronization task details and application logs for LDAP connection, bind, and search errors.

package/dist/ai/docs/nocobase/workflow/nodes/javascript.md

@@ -44,6 +44,26 @@ If checked, subsequent nodes will still be executed even if the script encounter
 If the script errors out, it will have no return value, and the node's result will be populated with the error message. If subsequent nodes use the result variable from the script node, it should be handled with caution.
 :::
 
+## Worker concurrency control
+
+JavaScript script nodes place pending scripts in a task queue and execute them in separate Worker threads. By default, NocoBase does not limit JavaScript script Worker concurrency. If multiple tasks are waiting in the queue, they can create Workers and run concurrently.
+
+If scripts consume a significant amount of memory while running, multiple Workers can quickly increase the memory usage of an application instance. In this case, use the `WORKFLOW_SCRIPT_WORKER_CONCURRENCY` environment variable to set a concurrency limit. The same applies to CPU-intensive scripts: excessive concurrency increases CPU contention and may affect other requests and workflows in NocoBase. You should also configure this variable if a large number of script tasks may be created within a short period:
+
+```bash
+WORKFLOW_SCRIPT_WORKER_CONCURRENCY=4
+```
+
+The configuration rules are as follows:
+
+- If the variable is unset or its value is invalid, concurrency is unlimited
+- A positive integer sets the maximum number of Worker threads that can run concurrently
+- A value of `0` removes the concurrency limit, allowing all queued tasks to run concurrently
+
+When the concurrency limit is reached, new tasks remain in the queue until a Worker becomes available. You can keep the default configuration if scripts run infrequently and each execution uses few resources. If you need a concurrency limit, start with a small value and adjust it gradually based on the application instance's memory and CPU usage and task queueing time.
+
+If an application runs on multiple server instances, this setting applies separately to each instance. The overall concurrency capacity also depends on the number of instances that can consume tasks. Restart the NocoBase service after changing the environment variable for the new value to take effect.
+
 ## Execution Engine
 
 The JavaScript script node supports two execution engines, automatically selected based on whether the `WORKFLOW_SCRIPT_MODULES` environment variable is configured:
@@ -164,4 +184,4 @@ async function sleep(time) {
 await sleep(1000);
 
 return 123;
-```
+```

package/dist/ai/tools/executeFrontendTool.d.ts

@@ -0,0 +1,10 @@
+/**
+ * This file is part of the NocoBase (R) project.
+ * Copyright (c) 2020-2024 NocoBase Co., Ltd.
+ * Authors: NocoBase Team.
+ *
+ * This project is dual-licensed under AGPL-3.0 and NocoBase Commercial License.
+ * For more information, please refer to: https://www.nocobase.com/agreement.
+ */
+declare const _default: import("@nocobase/ai").ToolsOptions;
+export default _default;

package/dist/ai/tools/executeFrontendTool.js

@@ -0,0 +1,86 @@
+/**
+ * This file is part of the NocoBase (R) project.
+ * Copyright (c) 2020-2024 NocoBase Co., Ltd.
+ * Authors: NocoBase Team.
+ *
+ * This project is dual-licensed under AGPL-3.0 and NocoBase Commercial License.
+ * For more information, please refer to: https://www.nocobase.com/agreement.
+ */
+
+var __create = Object.create;
+var __defProp = Object.defineProperty;
+var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
+var __getOwnPropNames = Object.getOwnPropertyNames;
+var __getProtoOf = Object.getPrototypeOf;
+var __hasOwnProp = Object.prototype.hasOwnProperty;
+var __export = (target, all) => {
+  for (var name in all)
+    __defProp(target, name, { get: all[name], enumerable: true });
+};
+var __copyProps = (to, from, except, desc) => {
+  if (from && typeof from === "object" || typeof from === "function") {
+    for (let key of __getOwnPropNames(from))
+      if (!__hasOwnProp.call(to, key) && key !== except)
+        __defProp(to, key, { get: () => from[key], enumerable: !(desc = __getOwnPropDesc(from, key)) || desc.enumerable });
+  }
+  return to;
+};
+var __toESM = (mod, isNodeMode, target) => (target = mod != null ? __create(__getProtoOf(mod)) : {}, __copyProps(
+  // If the importer is in node compatibility mode or this is not an ESM
+  // file that has been converted to a CommonJS file using a Babel-
+  // compatible transform (i.e. "__esModule" has not been set), then set
+  // "default" to the CommonJS "module.exports" for node compatibility.
+  isNodeMode || !mod || !mod.__esModule ? __defProp(target, "default", { value: mod, enumerable: true }) : target,
+  mod
+));
+var __toCommonJS = (mod) => __copyProps(__defProp({}, "__esModule", { value: true }), mod);
+var executeFrontendTool_exports = {};
+__export(executeFrontendTool_exports, {
+  default: () => executeFrontendTool_default
+});
+module.exports = __toCommonJS(executeFrontendTool_exports);
+var import_ai = require("@nocobase/ai");
+var import_zod = require("zod");
+var import_frontend_tools = require("../../common/frontend-tools");
+var import_frontend_tools2 = require("../../server/frontend-tools");
+var import_package = __toESM(require("../../../package.json"));
+var executeFrontendTool_default = (0, import_ai.defineTools)({
+  scope: "GENERAL",
+  execution: "frontend",
+  defaultPermission: "ALLOW",
+  introduction: {
+    title: `{{t("Execute frontend tool", { ns: "${import_package.default.name}" })}}`,
+    about: `{{t("Execute a frontend tool provided by the selected block.", { ns: "${import_package.default.name}" })}}`
+  },
+  definition: {
+    name: import_frontend_tools.EXECUTE_FRONTEND_TOOL_NAME,
+    description: "Execute a frontend tool from the current frontendToolCatalog. Use loadFrontendTool first when you need its input schema. Never use a tool id that is not present in the current catalog.",
+    schema: import_zod.z.object({
+      toolId: import_zod.z.string().describe("The exact tool id from the current frontendToolCatalog."),
+      args: import_zod.z.record(import_zod.z.string(), import_zod.z.unknown()).default({}).describe("Arguments that match the loaded frontend tool schema.")
+    })
+  },
+  invoke: async (ctx, args, runtime) => {
+    const tool = await (0, import_frontend_tools2.findCurrentFrontendTool)(ctx, args.toolId);
+    if (!tool) {
+      return {
+        status: "error",
+        content: "Frontend tool is unavailable in the current conversation."
+      };
+    }
+    const result = await (0, import_frontend_tools2.readFrontendToolResult)(ctx, runtime.toolCallId);
+    if (!(result == null ? void 0 : result.provided)) {
+      return {
+        status: "error",
+        content: "Frontend tool did not return a result."
+      };
+    }
+    if ((0, import_frontend_tools.isFrontendToolInvokeResult)(result.value)) {
+      return result.value;
+    }
+    return {
+      status: "success",
+      content: result.value
+    };
+  }
+});

package/dist/ai/tools/getSkill.js

@@ -43,7 +43,7 @@ var import_ai = require("@nocobase/ai");
 var import_zod = require("zod");
 var import_package = __toESM(require("../../../package.json"));
 var getSkill_default = (0, import_ai.defineTools)({
-  scope: "GENERAL",
+  scope: "SPECIFIED",
   defaultPermission: "ALLOW",
   introduction: {
     title: `{{t("Load specific SKILLS", { ns: "${import_package.default.name}" })}}`,