docs: cover dashboard-embed toggle API, dev-mode branch writes, devmode deep link, email unsubscribe - #11357
docs: cover dashboard-embed toggle API, dev-mode branch writes, devmode deep link, email unsubscribe#11357keydunov wants to merge 1 commit into
Conversation
|
Claude finished @keydunov's task in 38s —— View job Code ReviewVerdict: LGTM — docs-only, well-scoped, no issues found. Details
What was checked
Minor observations (non-blocking)
Nothing here blocks merge. |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…d devmode deep link Rebased onto master after #11353 and #11359 merged. Two changes from the original version are dropped as redundant: - The scheduled-refreshes unsubscribe paragraph: #11353 already landed the same note at the same place, and covers more (embed users and editor-added recipients). - The cli.mdx version banner and `embed` command-table row: #11359 already landed both. What remains is unique to this change: - api.yaml / docs.json: PATCH /v1/embed/dashboard/{publicId} to toggle signed embedding for a dashboard. - data-model-ide.mdx: ?devmode=true deep link, combinable with ?branch=. - cli.mdx: data-model file writes (put/delete/rename) are only accepted on a dev-mode branch; --dev-mode forks a personal dev-… branch that write commands must target. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0dc9bcb to
c393da1
Compare
|
Claude finished @keydunov's task in 2m 25s —— View job Code ReviewVerdict: request changes — 0 high, 2 medium, 2 low. The Details
Medium1. 2.
Both depend on cubejs-enterprise behavior I can't see from this repo — worth a quick confirmation against the CLI rather than taking the PR description at face value. Low
Verified clean
No security, performance, or test-coverage surface here — the change is docs-only, so those review axes are N/A. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| You can also link directly into development mode by adding `?devmode=true` to | ||
| the Data Model page URL — combine it with `?branch=<name>` to enter dev mode | ||
| on a specific branch, or omit `?branch` to use the currently selected branch. | ||
| The parameter only takes effect if you already have access to enter dev mode; | ||
| otherwise it's ignored. | ||
|
|
There was a problem hiding this comment.
This duplicates content that's already on master: docs/data-modeling/dev-mode.mdx:62-77 has a "Deep-link into development mode" section documenting both ?devmode=true and ?branch=, including the working combined URL and the permission no-op caveat.
Two problems with duplicating it here:
docs-mintlify/CLAUDE.mdsays "Say it once." Two copies of the same URL-param contract will drift.- This copy is less precise — "combine it with
?branch=<name>" without showing the join reads as?devmode=true?branch=x. Thedev-mode.mdxversion shows the correct form:…/schema?branch=my-branch&devmode=true. It also omits that the params are stripped from the URL once applied.
Suggest replacing the paragraph with a pointer:
| You can also link directly into development mode by adding `?devmode=true` to | |
| the Data Model page URL — combine it with `?branch=<name>` to enter dev mode | |
| on a specific branch, or omit `?branch` to use the currently selected branch. | |
| The parameter only takes effect if you already have access to enter dev mode; | |
| otherwise it's ignored. | |
| You can also [deep-link directly into development | |
| mode](/docs/data-modeling/dev-mode#deep-link-into-development-mode) using the | |
| `?devmode=true` and `?branch=` URL parameters. |
| ```bash | ||
| cube data-model create-branch DEPLOYMENT_ID my-branch --dev-mode | ||
| cube data-model put DEPLOYMENT_ID model/cubes/orders.yml --file orders.yml --branch my-branch | ||
| # entered dev mode on dev-my-branch (forked from my-branch) | ||
| cube data-model put DEPLOYMENT_ID model/cubes/orders.yml --file orders.yml --branch dev-my-branch | ||
| cube data-model merge-to-default DEPLOYMENT_ID --branch my-branch -m "add orders cube" | ||
| ``` | ||
|
|
||
| `merge-to-default` merges into the deploy branch and rebuilds production. | ||
| `--dev-mode` forks a personal `dev-…` branch off the branch you named and | ||
| prints it — pass that forked name via `--branch` on write commands (or omit | ||
| `--branch` to use your active dev-mode branch). Writes to any other branch are | ||
| rejected. `cube data-model dev-mode DEPLOYMENT_ID my-branch` re-enters dev mode | ||
| the same way if you're not already in it. `merge-to-default` merges into the | ||
| deploy branch and rebuilds production. |
There was a problem hiding this comment.
Two accuracy concerns with the reworked example — both worth verifying against the actual CLI before merge:
1. The example's writes look like they get dropped. put now targets dev-my-branch, but merge-to-default still targets my-branch. If the fork is a real separate branch, my-branch doesn't contain the orders.yml write at the point merge-to-default runs, so the example promotes nothing. The old example was self-consistent because both commands used the same branch. Either merge-to-default should target the dev branch, or the example needs the intermediate step (commit, then merge back into my-branch) that the command table at line 154 lists.
2. dev-my-branch may not be the real fork name. docs/integrations/mcp-server.mdx:287 documents personal dev branches as dev-<user>-<hash>:
Every write goes to a personal dev branch named
dev-<user>-<hash>.
If that's the same mechanism, a reader who copies --branch dev-my-branch verbatim gets a rejected write, and the two pages now contradict each other on the naming scheme. Since the prose already says --dev-mode "prints it" and that omitting --branch uses the active dev-mode branch, the safest example is to just omit --branch on the write rather than hard-code a name that may not exist:
| ```bash | |
| cube data-model create-branch DEPLOYMENT_ID my-branch --dev-mode | |
| cube data-model put DEPLOYMENT_ID model/cubes/orders.yml --file orders.yml --branch my-branch | |
| # entered dev mode on dev-my-branch (forked from my-branch) | |
| cube data-model put DEPLOYMENT_ID model/cubes/orders.yml --file orders.yml --branch dev-my-branch | |
| cube data-model merge-to-default DEPLOYMENT_ID --branch my-branch -m "add orders cube" | |
| ``` | |
| `merge-to-default` merges into the deploy branch and rebuilds production. | |
| `--dev-mode` forks a personal `dev-…` branch off the branch you named and | |
| prints it — pass that forked name via `--branch` on write commands (or omit | |
| `--branch` to use your active dev-mode branch). Writes to any other branch are | |
| rejected. `cube data-model dev-mode DEPLOYMENT_ID my-branch` re-enters dev mode | |
| the same way if you're not already in it. `merge-to-default` merges into the | |
| deploy branch and rebuilds production. | |
| ```bash | |
| cube data-model create-branch DEPLOYMENT_ID my-branch --dev-mode | |
| # prints the personal dev-… branch it forked and entered | |
| cube data-model put DEPLOYMENT_ID model/cubes/orders.yml --file orders.yml | |
| cube data-model commit DEPLOYMENT_ID -m "add orders cube" | |
| cube data-model merge-to-default DEPLOYMENT_ID -m "add orders cube" |
--dev-mode forks a personal dev-… branch off the branch you named and
prints it — write commands default to your active dev-mode branch, or you can
pass the printed name via --branch. Writes to any other branch are rejected.
cube data-model dev-mode DEPLOYMENT_ID my-branch re-enters dev mode the same
way if you're not already in it. merge-to-default merges into the deploy
branch and rebuilds production.
(Adjust the exact command sequence to whatever the CLI actually requires — the point is that the example should be runnable end-to-end.)
This branch was successfully deployed
2 participants
Check List
Description of Changes Made
Routine sweep of recent cube-js/cube and cubedevinc/cubejs-enterprise changes against docs-mintlify turned up a few small customer-facing gaps:
PATCH /v1/embed/dashboard/{publicId}— new admin-only Control Plane API endpoint to enable/disable signed embedding for a dashboard (cubejs-enterprise #13274), paired with the newcube embed enable-dashboard/disable-dashboardCLI commands (feat(cube-cli): add embed enable-dashboard / disable-dashboard commands #11356). Added the endpoint +UpdateDashboardEmbeddingInput/DashboardEmbeddingResponseschemas toapi-reference/api.yaml, registered it indocs.json, and added the two CLI subcommands to theembedrow inreference/cli.mdx.dev-…branch forked by--dev-mode/dev-mode, not the branch name you passed in. The CLI reference's "Data model Git workflow" example still showed--branch my-branch, which is now rejected — updated the example and surrounding text to match the real flow.cubewith no subcommand now prints the installed CLI version before the help text (feat(cube-cli): show CLI version when run without a command #11344) — added a line to the Installation section.?devmode=truedeep link into the Data Model IDE (cubejs-enterprise #13237) — undocumented opt-in URL param (combinable with?branch=) to open the IDE straight into dev mode. Added a short paragraph todata-model-ide.mdx.scheduled-refreshes.mdx.Other recent
featcommits in both repos were reviewed and intentionally left out as not customer-facing percubejs-enterprise/.claude/shared/customer-facing-criteria.md(internal telemetry, cloud-provisioner infra plumbing, invisible pre-aggregation-matching improvements, in-app snippet-formatting polish).No feature found in this pass was large enough to warrant its own docs page, so no Linear ticket was filed.
Generated by Claude Code