From 55d4280411ceb104a8dc802dc8a7d47d113ff1b6 Mon Sep 17 00:00:00 2001 From: LagunaElectric <6085143+LagunaElectric@users.noreply.github.com> Date: Thu, 20 Nov 2025 09:59:51 -0500 Subject: [PATCH 1/7] feat: add dropbox sign docs --- .cursor/rules/commands/uqi-docs.mdc | 170 +++++++++++++++ website/docs/connect-data/reference/README.md | 45 ++-- .../connect-data/reference/dropboxsign.md | 199 ++++++++++++++++++ website/sidebars.js | 1 + 4 files changed, 400 insertions(+), 15 deletions(-) create mode 100644 .cursor/rules/commands/uqi-docs.mdc create mode 100644 website/docs/connect-data/reference/dropboxsign.md diff --git a/.cursor/rules/commands/uqi-docs.mdc b/.cursor/rules/commands/uqi-docs.mdc new file mode 100644 index 0000000000..c9edb8290d --- /dev/null +++ b/.cursor/rules/commands/uqi-docs.mdc @@ -0,0 +1,170 @@ +--- +description: Workflow instructions for the `@uqi_doc` command that scaffolds a new UQI reference doc, sidebar link, and README tile from a JSON config file. +alwaysApply: false +--- + +# UQI Docs Builder + +You are the `@uqi_doc` command. Your job is to turn a Unified Query Interface (UQI) configuration JSON into a complete docs update: generate a reference page in `website/docs/connect-data/reference/`, insert the page in the sidebar, and surface it in `website/docs/connect-data/reference/README.md`. Move fast, keep everything in sync, and mirror the authored tone used in existing SaaS reference pages. + +## Core Principles + +- Treat the JSON config as source of truth for available commands, field labels, tooltips, and UI hints. +- Match the voice, structure, and HTML helpers (`\`<dd>\``, code blocks, bullets) from existing SaaS docs. +- Prefer deterministic transformations over free-form prose; when improvising copy, ground it in the field metadata or upstream API facts. +- Respect alphabetical ordering in both the sidebar category and README tiles. + +## Required Inputs + +Collect these (ask the user if anything is missing): + +1. **Display name** (defaults to the JSON `name` field, but confirm if a doc-specific variant is needed). +2. **Docs slug** for the file + sidebar id (auto-derive from the last segment of `documentationLink`, override only if necessary). +3. **Category** for README tile + sidebar bucket (use `SaaS Integrations`). +4. **JSON path** for the UQI config (e.g., `/integrations/acme_crm_uqi_config.json`). +5. **Authentication summary** (OAuth vs. API key, scopes, etc.). +6. **Any product-specific callouts** (rate limits, preview status, etc.). + +## Kickoff Response + +1. Acknowledge the request, restate integration name + slug. +2. Confirm you’re starting the UQI docs workflow and will pause for confirmation after the outline. + +Example: + +```text +Roger — spinning up @uqi_doc for Acme CRM (`connect-data/reference/acme-crm`). I’ll parse the config and share the outline before drafting the page. +``` + +## Working Document + +- Create (or append to) a markdown file at `specs/uqi-docs/-.md`. +- Sections, in order: + 1. **Intake Snapshot** – bullets covering inputs, assumptions, and open questions. + 2. **Doc Outline** – headings + bullets describing planned sections. + 3. **JSON Notes** – tables or lists summarizing each command + parameters parsed from the config with file references (for example, ``acme_crm_uqi_config.json → identifier: owner``). + 4. **Copy Decisions** – any human-authored blurbs (connect steps, conceptual tips) you want to reuse verbatim. + 5. **Implementation Checklist** – ≤6 ordered steps. + 6. **Change Log** – bullet per file touched describing edits. + 7. **Validation** – commands run + manual checks. + 8. **Follow-ups** – optional backlog items. +- Update the same document through the workflow; do not spawn additional planning files. + +## Workflow + +### 1. Intake & Setup + +- Validate inputs, resolve ambiguous category/icon info. +- Record everything in **Intake Snapshot**. +- If data is missing, ask immediately; do not guess. + +### 2. Parse the JSON Config + +- Open the supplied JSON file (example: `acme_crm_uqi_config.json`). +- Identify: + - **Command list** inside `rootActionConfig.editor`: locate the drop-down with `configProperty: actionConfiguration.formData.command` to capture labels + values in order. + - Matching `SECTION_V2` blocks within the same `rootActionConfig.editor` array whose `identifier` equals each command value. + - Every field node inside a section (`QUERY_DYNAMIC_INPUT_TEXT`, `DROP_DOWN`, `CHECKBOX`, etc.). + - **Docs slug** by parsing the trailing path segment of `documentationLink` (e.g., `https://docs.appsmith.com/connect-data/reference/github` → slug `github`). + - **README icon URL** from `iconLocation` (these are already hosted on `https://assets.appsmith.com/...` and should be reused verbatim). +- For each field capture: + - `identifier` / `label`. + - Control type → inferred data type (text → string, number input → integer/number, checkbox → boolean, array inputs → array). + - Required flag. + - Tooltip / placeholder text for copy inspiration. +- Dump findings into a table inside **JSON Notes** so later steps stay mechanical. + +### 3. Draft the Doc Outline + +- Mirror the shape of the existing UQI reference pages under `website/docs/connect-data/reference/`: + 1. Intro paragraph describing what the integration enables. + 2. `## Connect ` section summarizing authentication (OAuth/API key instructions, prerequisite scopes, rate-limit warnings). + 3. `## Query ` master section listing each command as a `###` heading. + 4. Within each command, enumerate parameters with headings like ``#### Owner `string``` and wrap explanations in `\`<dd>\`` blocks. + 5. Optional `### Custom Action` guidance if the config exposes `CUSTOM_ACTION`. +- Share the outline (include planned headings + notable notes) in the **Doc Outline** section and wait for user confirmation before writing prose. + +### 4. Produce the Reference Page + +- File path: `website/docs/connect-data/reference/.md`. +- Top-of-file structure: + - `# ` + - Intro paragraph (2–3 sentences). + - `## Connect ` with bulleted or numbered steps. +- For each command: + - Add a 1–2 sentence description of what the command does and its return shape. +- Use `\`<dd>\`` blocks to hold detailed prose; cite where to find values (for example, point readers to the location of project IDs, workspace names, or resource URLs in the target platform). + - Include sample payloads using fenced code blocks when helpful (JSON arrays, numbers, etc.). + - Call out permissions, rate limits, or validation rules from the JSON/tooltips. +- If the JSON exposes enums (dropdown options), list them as bullet points inside the parameter description. +- Re-check for consistent heading depth (`#`, `##`, `###`, `####`), avoid MDX imports unless necessary, keep ASCII punctuation. + +### 5. Update the Sidebar + +- File: `website/sidebars.js`. +- Locate the correct category inside the `connect-data/reference` tree (APIs, Databases, SaaS Integrations, AI Integrations). +- Insert `'connect-data/reference/'` in alphabetical order. +- If the category already contains the slug, skip to README updates but note in Change Log. + +### 6. Update the Reference README + +- File: `website/docs/connect-data/reference/README.md`. +- Within the matching category grid (`## APIs`, `## Databases`, `## SaaS Integrations`, or `## AI Integrations`): + - Add a new `
` block mirroring existing cards. + - Image: + - Use the `iconLocation` URL from the JSON (hosted on `https://assets.appsmith.com/...`; do not rewrite or relocate it). + - Set descriptive `alt` text (`alt=""`). + - Link + bold label must point to `/connect-data/reference/`. +- Ensure layout stays consistent (indentation + closing tags) and alphabetical ordering within the grid. + +### 7. Validation + +- Run targeted checks noted in the working doc. At minimum: + - `cd website && npm run build` (or `pnpm --filter website build`) if time permits. + - If skipping build (e.g., doc-only change), manually re-read rendered Markdown for syntax errors and note the risk. +- Verify internal links: + - Markdown file renders headings correctly. + - Sidebar entry compiles (no typos in doc id). + - README tile image path resolves. +- Record results in **Validation**. + +### 8. Final Response + +Return one message covering: + +1. **Outcome Summary** – mention new doc path + sidebar/README updates. +2. **Artifacts** – link to the working doc + list of modified files. +3. **Validation** – commands run or explicit note if skipped. +4. **Next Steps** – only if follow-ups exist; otherwise “None”. + +Once the user confirms the changes are final prompt them to delete the specs/uqi_docs folder and it's contents. + +## Parameter-to-Docs Mapping Cheatsheet + +- `QUERY_DYNAMIC_INPUT_TEXT` → treat as `string` unless tooltip mentions arrays/numbers (then follow tooltip). +- `INPUT_TEXT` with `isRequired: false` → highlight optional. +- `DROP_DOWN` → document allowed values exactly as shown in `options`. +- `CHECKBOX`/boolean toggles → describe default behavior when unchecked. +- `CUSTOM_ACTIONS_CONFIG_FORM` → summarize how to craft arbitrary REST calls and reference the target platform’s REST documentation, similar to the “Custom Action” sections found in other SaaS docs. + +## Style Checklist + +- Use sentence case headings after the initial `#`. +- Always wrap parameter explanations in ``<dd>`` tags for visual parity with the sample doc. +- Provide at least one example where the JSON tooltip includes sample payloads (arrays, numbers). +- Keep command descriptions ≤3 sentences before diving into fields. +- Avoid duplicating content already covered in another parameter; instead cross-reference (“See `Owner` above”). + +## Failure Handling + +- Missing info? Pause and ask the user; log the blocker in **Intake Snapshot**. +- JSON discrepancies (e.g., command referenced but section missing): note in **Follow-ups**, proceed with available data, and highlight gap in final response. +- If build fails, capture the log snippet in **Validation**, fix if possible, otherwise report failure and mark next steps. + +## Example References + +- `website/docs/connect-data/reference/` → browse existing files to see canonical formatting for SaaS commands, parameter sections, and ``<dd>`` usage. +- `website/sidebars.js` → locate the appropriate category inside the “SaaS Integrations” (or relevant) section before inserting the new doc id. +- `website/docs/connect-data/reference/README.md` → card layout for surfacing the integration tile. + +Use these as blueprints but never hardcode vendor-specific text unless you’re documenting that vendor’s integration. diff --git a/website/docs/connect-data/reference/README.md b/website/docs/connect-data/reference/README.md index f286dd5586..2dc34b0007 100644 --- a/website/docs/connect-data/reference/README.md +++ b/website/docs/connect-data/reference/README.md @@ -242,20 +242,22 @@ Appsmith also supports integration with various Software as a Service (SaaS) pla + +
@@ -263,6 +265,15 @@ Appsmith also supports integration with various Software as a Service (SaaS) pla
+
+ + HubSpot + +
+ HubSpot +
+ +
-
+
-
+
+ +
+ + - -
- -
+
-
+
-
+
+ +
+ +
Zendesk diff --git a/website/docs/connect-data/reference/dropboxsign.md b/website/docs/connect-data/reference/dropboxsign.md new file mode 100644 index 0000000000..8023096565 --- /dev/null +++ b/website/docs/connect-data/reference/dropboxsign.md @@ -0,0 +1,199 @@ +# Dropbox Sign + +Dropbox Sign lets you create, update, and track signature requests without leaving Appsmith. Use these commands to kick off new agreements, resend or edit signer details, search existing requests, and download completed packets directly into your workflows. + +## Connect Dropbox Sign + +1. Create a new Dropbox Sign datasource in Appsmith and click **Authenticate**. +2. Sign in to your Dropbox Sign account (the flow mirrors GitHub OAuth) and approve Appsmith. +3. After the redirect, click **Test** to confirm the bearer token is stored, then save the datasource for reuse across queries. + +No custom scopes or API keys are required—Appsmith keeps the token and refresh details tied to your account connection. + +## Query Dropbox Sign + +Choose a command from the **Commands** dropdown to configure its fields. Each command returns the JSON response from Dropbox Sign so you can bind it to widgets, save it to a database, or trigger downstream actions. + +### Sign Create And Send Signature Request + +Creates a new signature request using uploaded file URLs, signer details, and optional email content. The response includes the signature request ID, status, and signer URLs. + +#### File Urls `array` +
+Required. Provide an array of file URLs that Dropbox Sign can fetch. Example: +``` +["https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf"] +``` +Ensure every URL is publicly accessible or already shared with Dropbox Sign; otherwise the request will fail with a 400 error. +
+ +#### Signers `array` +
+Required. Array of signer objects with `email_address`, `name`, and optional `order`. +``` +[ + { + email_address: "jack@example.com", + name: "Jack", + order: 0 + } +] +``` +Match the number of signers to the document routing you expect. Missing email addresses will prevent the request from sending. +
+ +#### Title `string` +
+Optional subject line shown inside Dropbox Sign. Use this to distinguish similar agreements or add internal references. +
+ +#### Subject `string` +
+Optional email subject delivered to signers. Keep it short and identifiable so recipients recognize the message. +
+ +#### Message `string` +
+Optional email body displayed to all signers. Include instructions or deadlines for clarity. Markdown is not supported; plain text only. +
+ +#### Cc Emails `array` +
+Optional list of CC recipients who should receive status notifications. Provide an array such as `["legal@example.com"]`. +
+ +#### Attachments `array` +
+Optional files signers must upload back before completion. Each entry needs a `name` and `signer_index` that matches the signer order. +``` +[ + { + name: "Jack Doe File", + signer_index: 0 + } +] +``` +
+ +#### Signing Options `object` +
+Optional configuration for allowed signature creation methods. Example payload: +``` +{ + draw: true, + type: true, + default_type: "draw" +} +``` +Unset fields fall back to the account-level defaults. +
+ +#### Additional Fields `object` +
+Optional feature flags such as hiding text tags, allowing declines, or overriding expiration. Example: +``` +{ + hide_text_tags: true, + allow_decline: true, + expires_at: 1672396800 +} +``` +Timestamps must be Unix epoch seconds. +
+ +### Sign Update Signature Request + +Updates signer metadata or expiration on an existing request. Use this when a signer changes their email or you need to extend deadlines. + +#### Signature Request Id `string` +
+Required. The unique ID returned from create/search operations (for example `fa5c8a0b0f492d768749333ad6fcc214c111e967`). +
+ +#### Signature Id `string` +
+Required. Identify the specific signer on the request (example `78caf2a1d01cd39cea2bc1cbb340dac3`). +
+ +#### Email `string` +
+Optional new email for the signer. Provide this or `Name` (or both) when updating contact details. +
+ +#### Name `string` +
+Optional signer display name. If you only change the name, leave the email blank. +
+ +#### Expire At `integer` +
+Optional Unix timestamp (seconds) to set a new expiration. Example `1685435660`. Dropbox Sign enforces maximum durations based on your plan. +
+ +### Sign Get Signature Request By Id + +Retrieves the latest status, metadata, and signer URLs for a single request. + +#### Signature Request Id `string` +
+Required. Use the ID from the create, search, or update commands to fetch the record. +
+ +### Sign Search Signature Requests + +Searches across requests with optional account, keyword, and pagination filters. Returns paginated collections you can feed into tables or filters. + +#### Account Id `string` +
+Optional team member account ID. Use `all` to search across the entire team; leaving it blank defaults to the authenticated account. +
+ +#### Query `string` +
+Optional free-text search string (for example `"John"`). Dropbox Sign matches signer names, emails, and metadata. +
+ +#### Pagination Parameters `object` +
+Optional object controlling page size, cursors, or order. Pass the structure expected by the Dropbox Sign API. If omitted, default pagination applies. +
+ +### Sign Cancel Incomplete Signature Request + +Cancels a draft or in-progress request that has not been fully executed. Use this to free up envelopes or stop mistaken sends. + +#### Signature Request Id `string` +
+Required. The ID of the incomplete request you want to cancel. +
+ +### Sign Download Files + +Downloads the finalized documents from a signature request. Useful when you need to archive PDFs or preview signatures inside Appsmith. + +#### Signature Request Id `string` +
+Required. The completed request to download. +
+ +#### File Type `string` +
+Optional. Choose the format returned by Dropbox Sign. Current dropdown options: `pdf`. Leave blank to use the default bundle type. +
+ +### Custom Action + +Build any Dropbox Sign REST call manually. The Custom Action form exposes the full HTTP editor so you can target endpoints that are not yet modeled in the command list. + +
+1. Pick the HTTP method, path, and query parameters documented in the Dropbox Sign API reference (https://developers.hellosign.com/api/reference/). +2. Use dynamic bindings to include authentication headers—`{{ datasource.authBearerToken }}` is injected automatically. +3. Provide the JSON body or multipart payload, then preview the response before saving. +
+ +## Troubleshooting + +- **Missing or invalid IDs:** Ensure you store `signatureRequestId` and `signatureId` from create/search responses. Requests fail with 404 if these IDs are truncated. +- **Auth prompts reappear:** If the datasource was deleted or credentials expired, re-open the datasource and click **Authenticate** to refresh the bearer token. +- **Payload validation:** Arrays such as `fileUrls`, `signers`, and `attachments` must be valid JSON. Wrap strings in double quotes and confirm timestamps are numeric seconds. +- **Downloads return empty files:** Verify the request has completed signatures; Dropbox Sign only generates files after all required signers finish. diff --git a/website/sidebars.js b/website/sidebars.js index e018102efa..94e2e95c6e 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -339,6 +339,7 @@ const sidebars = { 'connect-data/reference/aws-lambda', 'connect-data/reference/confluence', 'connect-data/reference/dropbox', + 'connect-data/reference/dropboxsign', 'connect-data/reference/gmail', 'connect-data/reference/google-docs', 'connect-data/reference/querying-google-sheets', From 57e3eded9a3dff97e871c670279f62503e6fe96b Mon Sep 17 00:00:00 2001 From: LagunaElectric <6085143+LagunaElectric@users.noreply.github.com> Date: Thu, 20 Nov 2025 09:59:51 -0500 Subject: [PATCH 2/7] feat: add dropbox sign docs --- .../connect-data/reference/dropboxsign.md | 23 +++++++++++-------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/website/docs/connect-data/reference/dropboxsign.md b/website/docs/connect-data/reference/dropboxsign.md index 8023096565..2273ebfc25 100644 --- a/website/docs/connect-data/reference/dropboxsign.md +++ b/website/docs/connect-data/reference/dropboxsign.md @@ -30,12 +30,15 @@ Ensure every URL is publicly accessible or already shared with Dropbox Sign; oth #### Signers `array`
Required. Array of signer objects with `email_address`, `name`, and optional `order`. -``` + +```json [ { - email_address: "jack@example.com", - name: "Jack", - order: 0 + "email_address": "jack@example.com" + , + "name": "Jack" + , + "order": 0 } ] ``` @@ -65,11 +68,13 @@ Optional list of CC recipients who should receive status notifications. Provide #### Attachments `array`
Optional files signers must upload back before completion. Each entry needs a `name` and `signer_index` that matches the signer order. -``` + +```json [ { - name: "Jack Doe File", - signer_index: 0 + "name": "Jack Doe File" + , + "signer_index": 0 } ] ``` @@ -107,12 +112,12 @@ Updates signer metadata or expiration on an existing request. Use this when a si #### Signature Request Id `string`
-Required. The unique ID returned from create/search operations (for example `fa5c8a0b0f492d768749333ad6fcc214c111e967`). +Required. The unique ID returned from create/search operations.
#### Signature Id `string`
-Required. Identify the specific signer on the request (example `78caf2a1d01cd39cea2bc1cbb340dac3`). +Required. Identify the specific signer on the request.
#### Email `string` From c856a96e84003b25506577195b7c7fb70c683649 Mon Sep 17 00:00:00 2001 From: LagunaElectric <6085143+LagunaElectric@users.noreply.github.com> Date: Thu, 20 Nov 2025 13:52:35 -0500 Subject: [PATCH 3/7] chore: add command artifact folder to gitignore --- .gitignore | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.gitignore b/.gitignore index 4d61b12bdc..326491e54c 100644 --- a/.gitignore +++ b/.gitignore @@ -38,3 +38,5 @@ website/_dogfooding/_swizzle_theme_tests website/i18n/**/* #!website/i18n/fr #!website/i18n/fr/**/* + +spec/**/* From 5ca103c3bcb0f131f03791b691ad7e882f20582c Mon Sep 17 00:00:00 2001 From: LagunaElectric <6085143+LagunaElectric@users.noreply.github.com> Date: Wed, 3 Dec 2025 23:40:27 -0500 Subject: [PATCH 4/7] task: add business badge --- website/docs/connect-data/reference/dropboxsign.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/website/docs/connect-data/reference/dropboxsign.md b/website/docs/connect-data/reference/dropboxsign.md index 2273ebfc25..f0ddbfdd17 100644 --- a/website/docs/connect-data/reference/dropboxsign.md +++ b/website/docs/connect-data/reference/dropboxsign.md @@ -1,4 +1,13 @@ -# Dropbox Sign +
+

Dropbox Sign

+ + + +
Dropbox Sign lets you create, update, and track signature requests without leaving Appsmith. Use these commands to kick off new agreements, resend or edit signer details, search existing requests, and download completed packets directly into your workflows. From fc7c6c6a09ceac87c494b49178743bde38fb8cbe Mon Sep 17 00:00:00 2001 From: LagunaElectric <6085143+LagunaElectric@users.noreply.github.com> Date: Thu, 4 Dec 2025 13:28:40 -0500 Subject: [PATCH 5/7] task: move cursor command to separate branch --- .cursor/rules/commands/uqi-docs.mdc | 170 ---------------------------- .gitignore | 2 - 2 files changed, 172 deletions(-) delete mode 100644 .cursor/rules/commands/uqi-docs.mdc diff --git a/.cursor/rules/commands/uqi-docs.mdc b/.cursor/rules/commands/uqi-docs.mdc deleted file mode 100644 index c9edb8290d..0000000000 --- a/.cursor/rules/commands/uqi-docs.mdc +++ /dev/null @@ -1,170 +0,0 @@ ---- -description: Workflow instructions for the `@uqi_doc` command that scaffolds a new UQI reference doc, sidebar link, and README tile from a JSON config file. -alwaysApply: false ---- - -# UQI Docs Builder - -You are the `@uqi_doc` command. Your job is to turn a Unified Query Interface (UQI) configuration JSON into a complete docs update: generate a reference page in `website/docs/connect-data/reference/`, insert the page in the sidebar, and surface it in `website/docs/connect-data/reference/README.md`. Move fast, keep everything in sync, and mirror the authored tone used in existing SaaS reference pages. - -## Core Principles - -- Treat the JSON config as source of truth for available commands, field labels, tooltips, and UI hints. -- Match the voice, structure, and HTML helpers (`\`<dd>\``, code blocks, bullets) from existing SaaS docs. -- Prefer deterministic transformations over free-form prose; when improvising copy, ground it in the field metadata or upstream API facts. -- Respect alphabetical ordering in both the sidebar category and README tiles. - -## Required Inputs - -Collect these (ask the user if anything is missing): - -1. **Display name** (defaults to the JSON `name` field, but confirm if a doc-specific variant is needed). -2. **Docs slug** for the file + sidebar id (auto-derive from the last segment of `documentationLink`, override only if necessary). -3. **Category** for README tile + sidebar bucket (use `SaaS Integrations`). -4. **JSON path** for the UQI config (e.g., `/integrations/acme_crm_uqi_config.json`). -5. **Authentication summary** (OAuth vs. API key, scopes, etc.). -6. **Any product-specific callouts** (rate limits, preview status, etc.). - -## Kickoff Response - -1. Acknowledge the request, restate integration name + slug. -2. Confirm you’re starting the UQI docs workflow and will pause for confirmation after the outline. - -Example: - -```text -Roger — spinning up @uqi_doc for Acme CRM (`connect-data/reference/acme-crm`). I’ll parse the config and share the outline before drafting the page. -``` - -## Working Document - -- Create (or append to) a markdown file at `specs/uqi-docs/-.md`. -- Sections, in order: - 1. **Intake Snapshot** – bullets covering inputs, assumptions, and open questions. - 2. **Doc Outline** – headings + bullets describing planned sections. - 3. **JSON Notes** – tables or lists summarizing each command + parameters parsed from the config with file references (for example, ``acme_crm_uqi_config.json → identifier: owner``). - 4. **Copy Decisions** – any human-authored blurbs (connect steps, conceptual tips) you want to reuse verbatim. - 5. **Implementation Checklist** – ≤6 ordered steps. - 6. **Change Log** – bullet per file touched describing edits. - 7. **Validation** – commands run + manual checks. - 8. **Follow-ups** – optional backlog items. -- Update the same document through the workflow; do not spawn additional planning files. - -## Workflow - -### 1. Intake & Setup - -- Validate inputs, resolve ambiguous category/icon info. -- Record everything in **Intake Snapshot**. -- If data is missing, ask immediately; do not guess. - -### 2. Parse the JSON Config - -- Open the supplied JSON file (example: `acme_crm_uqi_config.json`). -- Identify: - - **Command list** inside `rootActionConfig.editor`: locate the drop-down with `configProperty: actionConfiguration.formData.command` to capture labels + values in order. - - Matching `SECTION_V2` blocks within the same `rootActionConfig.editor` array whose `identifier` equals each command value. - - Every field node inside a section (`QUERY_DYNAMIC_INPUT_TEXT`, `DROP_DOWN`, `CHECKBOX`, etc.). - - **Docs slug** by parsing the trailing path segment of `documentationLink` (e.g., `https://docs.appsmith.com/connect-data/reference/github` → slug `github`). - - **README icon URL** from `iconLocation` (these are already hosted on `https://assets.appsmith.com/...` and should be reused verbatim). -- For each field capture: - - `identifier` / `label`. - - Control type → inferred data type (text → string, number input → integer/number, checkbox → boolean, array inputs → array). - - Required flag. - - Tooltip / placeholder text for copy inspiration. -- Dump findings into a table inside **JSON Notes** so later steps stay mechanical. - -### 3. Draft the Doc Outline - -- Mirror the shape of the existing UQI reference pages under `website/docs/connect-data/reference/`: - 1. Intro paragraph describing what the integration enables. - 2. `## Connect ` section summarizing authentication (OAuth/API key instructions, prerequisite scopes, rate-limit warnings). - 3. `## Query ` master section listing each command as a `###` heading. - 4. Within each command, enumerate parameters with headings like ``#### Owner `string``` and wrap explanations in `\`<dd>\`` blocks. - 5. Optional `### Custom Action` guidance if the config exposes `CUSTOM_ACTION`. -- Share the outline (include planned headings + notable notes) in the **Doc Outline** section and wait for user confirmation before writing prose. - -### 4. Produce the Reference Page - -- File path: `website/docs/connect-data/reference/.md`. -- Top-of-file structure: - - `# ` - - Intro paragraph (2–3 sentences). - - `## Connect ` with bulleted or numbered steps. -- For each command: - - Add a 1–2 sentence description of what the command does and its return shape. -- Use `\`<dd>\`` blocks to hold detailed prose; cite where to find values (for example, point readers to the location of project IDs, workspace names, or resource URLs in the target platform). - - Include sample payloads using fenced code blocks when helpful (JSON arrays, numbers, etc.). - - Call out permissions, rate limits, or validation rules from the JSON/tooltips. -- If the JSON exposes enums (dropdown options), list them as bullet points inside the parameter description. -- Re-check for consistent heading depth (`#`, `##`, `###`, `####`), avoid MDX imports unless necessary, keep ASCII punctuation. - -### 5. Update the Sidebar - -- File: `website/sidebars.js`. -- Locate the correct category inside the `connect-data/reference` tree (APIs, Databases, SaaS Integrations, AI Integrations). -- Insert `'connect-data/reference/'` in alphabetical order. -- If the category already contains the slug, skip to README updates but note in Change Log. - -### 6. Update the Reference README - -- File: `website/docs/connect-data/reference/README.md`. -- Within the matching category grid (`## APIs`, `## Databases`, `## SaaS Integrations`, or `## AI Integrations`): - - Add a new `
` block mirroring existing cards. - - Image: - - Use the `iconLocation` URL from the JSON (hosted on `https://assets.appsmith.com/...`; do not rewrite or relocate it). - - Set descriptive `alt` text (`alt=""`). - - Link + bold label must point to `/connect-data/reference/`. -- Ensure layout stays consistent (indentation + closing tags) and alphabetical ordering within the grid. - -### 7. Validation - -- Run targeted checks noted in the working doc. At minimum: - - `cd website && npm run build` (or `pnpm --filter website build`) if time permits. - - If skipping build (e.g., doc-only change), manually re-read rendered Markdown for syntax errors and note the risk. -- Verify internal links: - - Markdown file renders headings correctly. - - Sidebar entry compiles (no typos in doc id). - - README tile image path resolves. -- Record results in **Validation**. - -### 8. Final Response - -Return one message covering: - -1. **Outcome Summary** – mention new doc path + sidebar/README updates. -2. **Artifacts** – link to the working doc + list of modified files. -3. **Validation** – commands run or explicit note if skipped. -4. **Next Steps** – only if follow-ups exist; otherwise “None”. - -Once the user confirms the changes are final prompt them to delete the specs/uqi_docs folder and it's contents. - -## Parameter-to-Docs Mapping Cheatsheet - -- `QUERY_DYNAMIC_INPUT_TEXT` → treat as `string` unless tooltip mentions arrays/numbers (then follow tooltip). -- `INPUT_TEXT` with `isRequired: false` → highlight optional. -- `DROP_DOWN` → document allowed values exactly as shown in `options`. -- `CHECKBOX`/boolean toggles → describe default behavior when unchecked. -- `CUSTOM_ACTIONS_CONFIG_FORM` → summarize how to craft arbitrary REST calls and reference the target platform’s REST documentation, similar to the “Custom Action” sections found in other SaaS docs. - -## Style Checklist - -- Use sentence case headings after the initial `#`. -- Always wrap parameter explanations in ``<dd>`` tags for visual parity with the sample doc. -- Provide at least one example where the JSON tooltip includes sample payloads (arrays, numbers). -- Keep command descriptions ≤3 sentences before diving into fields. -- Avoid duplicating content already covered in another parameter; instead cross-reference (“See `Owner` above”). - -## Failure Handling - -- Missing info? Pause and ask the user; log the blocker in **Intake Snapshot**. -- JSON discrepancies (e.g., command referenced but section missing): note in **Follow-ups**, proceed with available data, and highlight gap in final response. -- If build fails, capture the log snippet in **Validation**, fix if possible, otherwise report failure and mark next steps. - -## Example References - -- `website/docs/connect-data/reference/` → browse existing files to see canonical formatting for SaaS commands, parameter sections, and ``<dd>`` usage. -- `website/sidebars.js` → locate the appropriate category inside the “SaaS Integrations” (or relevant) section before inserting the new doc id. -- `website/docs/connect-data/reference/README.md` → card layout for surfacing the integration tile. - -Use these as blueprints but never hardcode vendor-specific text unless you’re documenting that vendor’s integration. diff --git a/.gitignore b/.gitignore index 326491e54c..4d61b12bdc 100644 --- a/.gitignore +++ b/.gitignore @@ -38,5 +38,3 @@ website/_dogfooding/_swizzle_theme_tests website/i18n/**/* #!website/i18n/fr #!website/i18n/fr/**/* - -spec/**/* From f0706ed83aeb4d587300aadd83ca6ce25e3c09b9 Mon Sep 17 00:00:00 2001 From: LagunaElectric <6085143+LagunaElectric@users.noreply.github.com> Date: Thu, 4 Dec 2025 13:32:50 -0500 Subject: [PATCH 6/7] task: add front matter --- website/docs/connect-data/reference/dropboxsign.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/website/docs/connect-data/reference/dropboxsign.md b/website/docs/connect-data/reference/dropboxsign.md index f0ddbfdd17..b63f267061 100644 --- a/website/docs/connect-data/reference/dropboxsign.md +++ b/website/docs/connect-data/reference/dropboxsign.md @@ -1,4 +1,11 @@ -
+--- +title: Asana +hide_title: true +--- + + + +<

Dropbox Sign

+ + Dropbox Sign lets you create, update, and track signature requests without leaving Appsmith. Use these commands to kick off new agreements, resend or edit signer details, search existing requests, and download completed packets directly into your workflows. ## Connect Dropbox Sign From 8c20ee6e1f3ee55ef5dcbd294c1cd97bf2d92152 Mon Sep 17 00:00:00 2001 From: Laguna <6085143+LagunaElectric@users.noreply.github.com> Date: Fri, 5 Dec 2025 11:52:22 -0500 Subject: [PATCH 7/7] fix: rename title from 'Asana' to 'Dropbox Sign' --- website/docs/connect-data/reference/dropboxsign.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/connect-data/reference/dropboxsign.md b/website/docs/connect-data/reference/dropboxsign.md index b63f267061..a175f11bac 100644 --- a/website/docs/connect-data/reference/dropboxsign.md +++ b/website/docs/connect-data/reference/dropboxsign.md @@ -1,5 +1,5 @@ --- -title: Asana +title: Dropbox Sign hide_title: true ---