From SDK demo to a working dashboard.

What is in the download?

The ZIP contains integration source and the SDK. Keep your application’s API client, login system and production configuration.

• richscripts-actions.js — the browser SDK used by both examples.
• ZChatInboxActionAssistant.tsx — install as InboxActionAssistant.tsx in React, beside the SDK and richscripts-actions.d.ts.
• zchat-inbox-actions.css — import these scoped styles into your React application. Download styles.
• mylivechat-dashboard-actions.js — install as richscripts-dashboard-actions.js and load after the SDK in the authenticated master page.
• README.txt and index.html — installation notes and this walkthrough.

React requires the host API modules shown in the example. This package is not a standalone dashboard or a replacement for your existing backend.

1. Start with the application's authorization boundary

Locate the current application, its login mechanism, workspace or customer identity, and existing read endpoints. Review repository instructions and existing changes before editing. Keep production secrets on the server and reuse the application's authenticated request client. Do not ship an API key in a JavaScript bundle.

ZChat uses a same-origin backend-for-frontend. Its operator session supplies identity, workspace membership, and role context to the upstream API. MyLiveChat's dashboard pages obtain the current account on the server. The assistant adds a way to reach these existing operations; it does not grant additional access.

2. Register a small, explicit action catalog

Validate enum values, query lengths and positive integer bounds. Use fixed destination routes and URLSearchParams for query encoding. Reject unsupported commands. The SDK validates its flat argument schemas, while server authorization remains authoritative.

3. Integrate ZChat's React inbox

Place the SDK and component beside the application's inbox components. Import the SDK once, mount it in useEffect, and destroy it on cleanup. A disposed flag prevents late query results from updating an unmounted component. Render the assistant only after the inbox's initial load succeeds.

import InboxActionAssistant from "../components/InboxActionAssistant";

{!loading && loadError === null &&
  <InboxActionAssistant onOpenConversation={setSelectedId} />}

// Registered read action uses the existing authenticated API client:
const rows = await api.getInbox({
  take: 50, statusFilter: args.status, q: args.query
});

// Check thread access before selecting it:
await api.getConversation(args.id);
onOpenConversation(args.id);

The downloaded component expects the host application's api/client and api/types modules, including InboxItemDto. Rename the file to InboxActionAssistant.tsx when installing it. The host supplies the selected-conversation callback. This is integration source, not a standalone React application. The query panel shows at most 50 matches; it is not a complete paginated search interface.

4. Integrate MyLiveChat's classic dashboard

Load the SDK first, then the dashboard adapter near the end of the authenticated master template. The adapter mounts a collapsed details panel at #main-content. It deliberately inserts the panel outside the ASP.NET form, and gives every shortcut button type="button", so submitting a command cannot submit the account settings form.

<script charset="utf-8" src="/dashboard/richscripts-actions.js?v=0.4.0"></script>
<script charset="utf-8" src="/dashboard/richscripts-dashboard-actions.js?v=RELEASE_VERSION"></script>

The download is named mylivechat-dashboard-actions.js; install it as richscripts-dashboard-actions.js to match the loader above. Update RELEASE_VERSION whenever publishing a changed adapter. English commands and Chinese commands such as 查看待处理工单 and 搜索账单 are supported. Search results are displayed by existing pages; the assistant does not fetch or retain customer data independently.

5. Test behavior, permissions and layout

• Run JavaScript syntax checks, React type checks and a production build. For ASP.NET page or server changes, run the project's precompile check.
• Use browser tests for successful commands, encoded search terms, unsupported writes, result selection, and narrow layouts at 390, 768 and 1440 pixels.
• Verify the assistant is outside the classic ASP.NET form. Confirm command execution performs only expected reads or navigation.
• Use test fixtures to validate the adapter without customer data. Fixture tests do not establish that every live role and workspace is correct.
• Verify production login redirects, then test with authorized accounts covering allowed and denied workspace access. Never bypass login for the assistant.

The initial releases passed syntax/build checks, relevant browser tests, and live resource checks. ZChat's browser test used mocked authenticated API responses. Live unauthenticated checks confirmed login redirects; a full signed-in production role matrix was not performed during this walkthrough.

6. Package, deploy and verify

Publish only the intended application. ZChat's React output is included in the dashboard's .NET publish package. Apply the project's production IIS web.config overlay: the first publish exposed a locked WebSocket configuration section, and service was restored using the established production overlay. Preserve the server's appsettings.Production.json and avoid uploading development settings.

For MyLiveChat, start with the current remote master template and add only the script loaders. Upload the two static scripts before enabling the template. Back up replaced files, check that the remote baseline has not changed, and read every uploaded file back to compare its hash. This avoids deploying unrelated local template changes.

An FTPS timeout while ending a data connection does not prove success or failure. Reconnect and compare the full remote file before proceeding. After release, check the login page, exact JavaScript bytes, static assets, and unauthenticated dashboard redirects. Use a new release version for browser/CDN cache invalidation. If the application fails to start, restore the previous compatible package and configuration.

Adding model inference or write actions later

Keep the command integration working before adding inference. A server resolver may propose registered actions, but it must not execute arbitrary code. Reuse the application's AI metering and limits; do not call a provider directly around billing. For writes, bind the proposed action and arguments to the signed-in user and tenant on the server, require confirmation, check expiry, and execute inside the application's transaction and audit system. Durable idempotency must survive retries and process restarts. Browser confirmation alone is insufficient authorization.

Frequently asked questions