docs: correct series mapping to match the chart builder, and two custom-roles details - #11521
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
Claude finished @igorlukanin's task in 1m 40s —— View job Review complete — 3 findings (0 blocking, 3 medium: cross-page inconsistencies)Corrections themselves look right; each one leaves a sibling page or table stating the old model. Full reviewTodos
What I could and could not verifyThe Cube chart builder frontend and the roles UI are not in this repo, so I also confirmed the Findings
Details and suggested fixes are in the inline comments. Smaller notes (not worth blocking)
Non-applicable review dimensionsSecurity, performance, and test coverage don't apply — this is a 13/12-line docs-only diff with no code, no config, and no navigation ( |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
Claude finished @igorlukanin's task in 1m 53s —— View job Re-review after
|
| # | Was | Now |
|---|---|---|
| 1 | scatter.mdx / map.mdx still documented a Size channel |
scatter.mdx:24-26 now says the Fields tab has no Size channel and routes readers to the Vega spec editor + the Style-tab Size legend; map.mdx:42,51 renamed to Custom size with the Default-size fallback explained. The stale "size field token" screenshot placeholder is gone. |
| 2 | tooltips.mdx:20-22 still described dragging from Available fields |
Rewritten to the row/dropdown model, plus + Tooltip, the per-row ×, and the note that toggling the section off and back on restores the automatic tooltip. The dropped Reorder fields row is correctly reflected in the frontmatter-adjacent intro ("and in what order" removed). |
| 3 | DeploymentAgentRead mentioned only in the Tip |
Added to the granular Actions table (custom-roles.mdx:122) and the catalog (:261). The commit went further and added SqlRunnerRead and PreAggregationBuild, and re-ordered both tables to match each other. |
Verification
All four action names check out against the RoleWithAccess.actions enum in docs-mintlify/api-reference/api.yaml:7791-7814 — APMRead, PreAggregationBuild, SqlRunnerRead, DeploymentAgentRead. The catalog table's ordering now mirrors the Actions table, which makes the two easy to diff by eye.
The chart-builder frontend still isn't in this repo, so the UI claims (size encoding surfacing a Style-tab Size section, the + Tooltip button, the toggle-restores-automatic behavior) remain on the author's word — I checked internal consistency only. Repo-wide grep for Available fields and field token across docs-mintlify/ now returns nothing; the remaining drag hits are table.mdx, pie.mdx, and kpi.mdx, all about genuinely different UI (column reorder, pivot drop zone, radius slider, KPI block handles).
New findings
| # | File | Issue |
|---|---|---|
| 1 | custom-roles.mdx:71 |
The auto-bump rule still says any action "stronger than Access deployment" forces Developer, while the Tip at :133 names three exemptions. Adding a second exception turns a rounding into a contradiction. |
| 2 | series-mapping.mdx:23,37 |
"Each channel is a dropdown" / "the × on its dropdown" covers Tooltip, which tooltips.mdx — rewritten in this same PR — describes as a repeatable row list with one dropdown per row. |
Both have suggested edits in the inline comments.
Smaller notes (not worth blocking)
scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdx:12-19has no data labels row. One of the two enumerations is incomplete.series-mapping.mdx:8— the screenshot caption still lists only "X, Y, Color and Tooltip" while the table also has Split by and Theta. Carried over from the previous pass.series-mapping.mdx:33— still no stated way out of multi-series mode once Color is pinned to Series. Carried over.series-mapping.mdx:18says Tooltip (singular);tooltips.mdxcalls the UI section Tooltips. Worth matching the product label.custom-roles.mdx:133— the serial-comma / 1:1 reason mapping suggestion from last time was applied. Nice.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 37/32 lines, no code, config, or docs.json navigation changes. All five files are existing pages edited surgically, matching docs-mintlify/CLAUDE.md's preference for editing over adding.
…tip channel's shape
|
Claude finished @igorlukanin's task in 1m 31s —— View job Re-review after
|
| # | Was | Now |
|---|---|---|
| 1 | Auto-bump rule said "stronger than Access deployment" while the Tip named three exemptions | custom-roles.mdx:71 now enumerates all three, so the Tip at :133 reads as a restatement rather than a contradiction |
| 2 | "Each channel is a dropdown" / "the × on its dropdown" contradicted the row-list model in tooltips.mdx |
series-mapping.mdx:23 carves Tooltip out with a link to the sibling page, and :37 explains that the tooltip × removes one row |
Verification
Both tables in custom-roles.mdx are now consistent with each other and with the RoleWithAccess.actions enum in api-reference/api.yaml — 12 granular deployment actions plus All, in the same order in the Actions table (:112–125) and the catalog (:250–264). DownloadData, DeploymentAgentRead, SqlRunnerRead, PreAggregationBuild all check out at api.yaml:7786,7792,7799,7814.
The role builder and chart frontend still aren't in this repo, so which actions actually trigger the bump is unverifiable here — that's exactly what the new finding turns on.
New finding
| # | File | Issue |
|---|---|---|
| 1 | custom-roles.mdx:71 |
The exemption list is now exactly three actions, but the Create an Explorer walkthrough at :175 has an Explorer base role checking Access query history (APMRead) — not exempt, so that step would force Developer and disable the Explorer chosen at :169. Same question for View data model (SchemaRead). |
Details and both possible fixes are in the inline comment.
Smaller notes (not worth blocking)
series-mapping.mdx:18lists the Tooltip channel's applicable types as "All types", buttooltips.mdx:12scopes tooltips to the Vega-based types (bar, line, area, scatter, heatmap, boxplot) plus map — which leaves out pie, table, and KPI. Untouched by this commit, but the two pages now sit one link apart.series-mapping.mdxcalls the channel Tooltip (singular) whiletooltips.mdxcalls the UI section Tooltips. Carried over from the last pass.series-mapping.mdx:8— screenshot caption still lists only "X, Y, Color and Tooltip" while the table also has Split by and Theta. Carried over.series-mapping.mdx:33— still no stated way out of multi-series mode once Color is pinned to Series. Carried over.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, no code, config, or docs.json navigation changes. This commit touches 2 lines across 2 existing pages.
… action that bumps to Developer
|
Claude finished @igorlukanin's task in 1m 4s —— View job Re-review after
|
…t of multi-series mode
|
Went through the carried-over notes against the builder rather than the page, and three of them were real product mismatches rather than wording:
Also renamed Split by to Small multiples in the channel table: that's the section heading, "Split by" is only the picker's placeholder, which is what All in |
|
Claude finished @igorlukanin's task in 2m 14s —— View job Re-review after
|
| Was | Now |
|---|---|
| Screenshot caption listed only "X, Y, Color and Tooltip" while the table also had Split by and Theta | :8 now lists X, Y, Color, Small multiples and Tooltip, which matches the table exactly |
Tooltip channel claimed "All types" while tooltips.mdx scoped it to Vega types plus map |
:18 now scopes it to "Vega-based types, pie, and map — but not table, KPI, or HTML", and tooltips.mdx:12 was widened to include pie in the same commit |
| No stated way out of multi-series mode once Color is pinned to Series | :36 adds the exit path |
| Tooltip (singular) vs the Tooltips section label | Both pages now use Tooltips for the UI section and reserve Tooltip for the channel; :17 handles the same split for Small multiples / Split by explicitly |
Renaming Split by → Small multiples agrees with small-multiples.mdx:14 ("The Small multiples section appears in the Fields tab") while the "its dropdown is labelled Split by" clause keeps :16 and :22 of that page findable. Dropping the Theta (pie) row strands nothing — Theta now appears nowhere in docs-mintlify/.
New findings
| # | File | Issue |
|---|---|---|
| 1 | series-mapping.mdx:32-36 |
The rewrite removes the only statement of how to enter multi-series mode (was: "set the Color channel to Series"). The one page that still documents entry — series-configuration.mdx:6,22 — calls it the "Y-axis section" and says "Add two measures to the Y axis", the model this PR's description calls wrong. |
| 2 | series-mapping.mdx:20 |
Pie Rings and Measure appear nowhere else in the docs, and chart-types/pie.mdx contradicts the innermost-ring color rule ("colored using the active color palette in palette order, matched to the sort order of your query results") while never mentioning rings at all. |
Both have suggested directions in the inline comments.
Verification
The chart builder frontend isn't in this repo, so the UI claims new in this commit — the Rings/Measure pie panel, the checklist tooltip control on pie and map, the absence of a tooltip switch there — remain on the author's word. What I checked is internal consistency:
map.mdx:86-88documents a Tooltips section and links totooltips.mdxwithout asserting rows or ordering, so the new pie/map checklist paragraph doesn't contradict it.- "Table, KPI, and HTML charts have no tooltip control" holds against those three pages;
table.mdx:48mentions a hover tooltip for truncated cells, but that's cell-overflow text, not the configurable channel. docs.jsonis untouched, and no page links to#multiple-measures-on-yor any other heading this PR renamed.
Smaller notes (not worth blocking)
scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table here has no data labels row. Defensible if data labels aren't a channel, but the two enumerations read as if they're the same list. Carried over.tooltips.mdx:12now says the default tooltip contains "the fields assigned to its channels (X, Y, Color)" and includes pie in the enabled-by-default list — butseries-mapping.mdx:20says pie has none of those three channels, leaving a pie's default tooltip contents unstated.series-mapping.mdx:3— the frontmatter description still reads "X axis, Y axis, color, and tooltips" and omits small multiples. Pre-existing.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 17/9 lines across two existing pages, no code, config, or docs.json navigation changes.
… panel with the pie page
|
Claude finished @igorlukanin's task in 2m 3s —— View job Re-review after
|
| # | Was | Now |
|---|---|---|
| 1 | The multi-series section said how to leave the mode but never how to enter it, and series-configuration.mdx called the section "Y-axis section" |
series-configuration.mdx:6 now covers both cases ("With one measure that is the Y-axis section; with several, the Y channel is replaced by a Series section") and cross-links here, so the two pages name the same thing. series-mapping.mdx:32 restores an entry statement — but see new finding 1: it's an action with no control behind it. Half-fixed. |
| 2 | Pie Rings / Measure existed only in one clause here, and pie.mdx contradicted the innermost-ring color rule |
The clause was split so the palette does the coloring and the ring only picks the dimension, which removes the direct contradiction. But the sentence now says this is "as described on the pie & donut page", and that page still never mentions rings — see new finding 3. Half-fixed. |
New findings
| # | File | Issue |
|---|---|---|
| 1 | series-mapping.mdx:32 |
"Put more than one measure on the Y axis" is an action with no control: line 24 says each channel is a single dropdown, Tooltip being the only exception. Mirror image of the gap the last commit had. |
| 2 | series-mapping.mdx:34 |
Color pinned to Series in multi-series mode vs series-configuration.mdx:30-32, which says the per-series color picker "has no effect when a Color channel is active" — the page line 32 links to for exactly those settings. |
| 3 | series-mapping.mdx:20 |
The new "as described on the [pie & donut] page" pointer cites a claim pie.mdx:28-30 doesn't make; Rings is still defined nowhere but this clause. |
All three have suggested edits in the inline comments.
Verification
The chart builder isn't in this repo, so the product claims new in this commit — that a second Y measure is what triggers the fold, that a pie's default tooltip spans the query rather than a channel set — remain on the author's word; I checked internal consistency only.
What holds up: Theta and Split by-as-a-section still appear nowhere in docs-mintlify/, small-multiples.mdx:14 agrees with the renamed channel row, and no page links to a heading this PR renamed. custom-roles.mdx is untouched by this commit and its two tables still match the RoleWithAccess.actions enum in api-reference/api.yaml:7786-7814. docs.json is untouched.
Smaller notes (not worth blocking)
tooltips.mdx:14— "covers every member of the query … any member you have not unchecked" uses member, which isn't this section's vocabulary (the rest of the page says field and column; the only other chart-docs use of "member" istable.mdx:184, for drill members). It also describes a default in terms of unchecking, which reads as the configured state. "its default tooltip includes every field in the query, in ring order" would say it plainly.tooltips.mdx:14also leans on "ring order" — the third page to reference rings without defining them. Finding 3's fix would give it something to point at.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table has no data labels row. Carried over.series-mapping.mdx:36— "Removing the second-to-last one drops the chart back to a single measure" still describes the transition from the removal's perspective rather than the resulting state. Cosmetic.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 6 lines across 3 existing pages in this commit, no code, config, or docs.json navigation changes.
…res to the Y axis' phrasing
|
Claude finished @igorlukanin's task in 1m 35s —— View job Re-review after
|
| # | Was | Now |
|---|---|---|
| 1 | series-mapping.mdx:34 said a layer "takes one measure, so the Series section appears only for the measures within a single layer" — a nesting its own premise forbade |
The rule is now applied inside each layer rather than asserted as containment: "Each layer has its own copy of the Fields controls and the rule above applies inside each one separately". That's a coherent statement of the relationship, and it drops the "do not compete" hand-wave. |
| 2 | line.mdx:18 still said "add multiple measures to the Y axis to plot them as separate series" |
Now "query several measures to plot each as its own series", which matches series-mapping.mdx:32's query-driven model. Repo-wide, no page says "measures to the Y axis" any more. |
New finding
| # | File | Issue |
|---|---|---|
| 1 | series-mapping.mdx:34 |
The new wording admits "a layer showing several [measures]", while series-configuration.mdx:6 says a layer has "its own measure" (singular, and the walkthrough picks one) — and :8 uses the absence of a Series list as the reader's test for which mode they're in, which stops discriminating in the mixed case this line now allows. |
Low severity: both pages are internally consistent and the seam only opens if a single layer can actually fold. Suggested wording for either answer is in the inline comment.
Verification
The chart builder isn't in this repo, so whether a single layer can hold several measures — the thing finding 1 turns on — is unverifiable here. Internal consistency is what I checked:
bar.mdx:44andline.mdx:42still give the same three steps for the composite recipe, both starting at + Y Axis.charts/index.mdx:33andcharts/configuration/index.mdx:11both describe series configuration as "per Y-axis layer" and neither promises per-series color, matching the moved Mark color section.custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Smaller notes (not worth blocking)
color-and-stacking.mdx:72,bar.mdx:60,series-configuration.mdx:16,40,48,axes.mdx:39— all still say "series" for the thing that carries settings, which this PR standardized on "layer". Cosmetic, but it's the vocabulary split that made rounds 5–8 ambiguous; a sweep would retire the ambiguity for good.series-mapping.mdx:32vs:40—:32calls multi-series "a property of the query rather than a channel you set", then:40says you leave the mode with the × in the Series section. Consistent only if that × edits the query, which neither page says. Carried over.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from six rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 2 additions / 2 deletions across 2 existing pages in this commit, no code, config, or docs.json navigation changes.
…by their shape on the Fields tab
|
Claude finished @igorlukanin's task in 1m 34s —— View job Re-review after
|
| Was | Now |
|---|---|
series-mapping.mdx:34 admitted "a layer showing several [measures]", while series-configuration.mdx:6 gave a layer "its own measure" (singular) and :8 used the absence of a Series list as the reader's test — which stopped discriminating in the mixed case |
:6 now says a layer has "its own fields, mark type, and axis assignment", and :8 replaces the test with a structural one: "a layer is a repeat of the whole set of Fields controls … while multi-series is a Series list inside one such set. The two can coexist, so a layer can itself be in multi-series mode." That is checkable in the mixed case (count the copies of the controls) and matches series-mapping.mdx:34 exactly — "the rule above applies inside each one separately". |
Picking the structural tell over the query-shape tell is the right call: it's the third framing this seam has had across rounds 8–10, and it's the first one that stays true when both features are present at once.
New finding
| # | File | Issue |
|---|---|---|
| 1 | series-configuration.mdx:8 |
The paragraph opens with "nothing on this page applies to it" and closes with "a layer can itself be in multi-series mode" — under coexistence the layer's mark type and axis assignment do govern its folded series, so a reader in the mixed case can't tell whether the Mark type override section below is available to them. |
Suggested wording is in the inline comment. Low severity — it's a scoping clause, not a wrong instruction.
Verification
The chart builder isn't in this repo, so whether a single layer can fold — the claim this commit adds — is on the author's word. Internal consistency is what I checked:
- The walkthrough at
:23-26still works under the new premise: "Pick the measure it should plot" is one measure in a layer that could hold several, which the loosened wording permits. bar.mdx:44andline.mdx:42both still start the composite recipe at + Y Axis;charts/index.mdx:33andcharts/configuration/index.mdx:11both describe the page as per-Y-axis-layer.color-and-stacking.mdx:54andseries-mapping.mdx:38state the palette-by-position rule in the same terms.custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Smaller notes (not worth blocking)
series-mapping.mdx:36— "While the chart is in this multi-series mode, the Color channel stays pinned to Series" says the chart, but per the new coexistence rule the fold is per layer, so the pin presumably applies to that layer's Color channel. Same for:40's exit instruction.color-and-stacking.mdx:72,bar.mdx:60,series-configuration.mdx:16,36,42,48,axes.mdx:39— all still say "series" for the thing that carries settings, which this PR standardized on "layer". Cosmetic, but it's the vocabulary split that made rounds 5–10 ambiguous; a sweep would retire it for good.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from seven rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 2 additions / 2 deletions in one existing page in this commit, no code, config, or docs.json navigation changes.
…ot applying at all
|
Claude finished @igorlukanin's task in 1m 46s —— View job Re-review after
|
| Was | Now |
|---|---|
series-configuration.mdx:8 opened with "nothing on this page applies to it" and closed with "a layer can itself be in multi-series mode" — two clauses that read as opposites, leaving a reader with a folded layer unable to tell whether Mark type override was available |
The blanket denial is gone. The rows still "carry no settings of their own — so the settings on this page are never per-measure", but the paragraph now adds that they "still apply to the layer holding that Series section, and govern every series in it at once." That's the distinction the clause was missing: not per-row, but per-layer and applied to the whole group. |
Scoping the denial to per-measure rather than to the mode as a whole is the right cut — it's what makes the coexistence sentence at the end of the paragraph consistent with the rest of the page, and it agrees with series-mapping.mdx:38 ("The Series section itself carries no per-series settings — its rows only name a measure and remove it").
New finding
| # | File | Issue |
|---|---|---|
| 1 | series-configuration.mdx:8 |
The new clause presupposes a layer ("the layer holding that Series section"), but the sentence's subject is a chart that carries several series without layers — so the case the paragraph opens with is the one it doesn't answer, while :6 scopes the page to "a chart built from Y-axis layers". |
Suggested wording is in the inline comment. Low severity — it's a scoping gap, not a wrong instruction, and the answer is probably just "the global chart settings".
Verification
The chart builder isn't in this repo, so whether an unlayered multi-series chart has any per-series surface at all remains on the author's word. Internal consistency is what I checked:
color-and-stacking.mdx:54andseries-mapping.mdx:38still state the palette-by-position rule in the same terms, and both scope it to the pinned-Series case.- The walkthrough at
:22-26is unaffected: it starts at + Y Axis, so it's in the layered case the new clause covers. bar.mdx:44andline.mdx:42both still start the composite recipe at + Y Axis;charts/index.mdx:33andcharts/configuration/index.mdx:11both describe this page as per-Y-axis-layer and neither promises per-series color.custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Smaller notes (not worth blocking)
series-mapping.mdx:34— "Layers are also what carry per-series mark types" says per-series for what this commit establishes as a per-layer setting. Harmless when a layer holds one measure, ambiguous when it folds.series-configuration.mdx:16,36,40,42,48andaxes.mdx:39,bar.mdx:60,color-and-stacking.mdx:72— all still say "series" for the thing that carries settings, which this PR standardized on "layer". Cosmetic, but it's the vocabulary split that made rounds 5–11 ambiguous; a sweep would retire it for good.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from eight rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 1 addition / 1 deletion in one existing page in this commit, no code, config, or docs.json navigation changes.
|
Claude finished @igorlukanin's task in 1m 43s —— View job Re-review after
|
| Was | Now |
|---|---|
series-configuration.mdx:8 opened with a chart that carries several series without layers, then answered only the layered case ("They still apply to the layer holding that Series section"), leaving the paragraph's own subject unaddressed |
The sentence now branches explicitly: "On a chart with no layers they are simply the chart's own settings, governing every series at once; on a layered chart they belong to the layer holding that Series section." Both cases the paragraph raises now get an answer, and the structural tell at the end of the paragraph is unchanged. |
Splitting the clause by case rather than adding another qualifier is the right shape — it's the first version of this paragraph where each sentence's subject matches what the sentence resolves.
New finding
| # | File | Issue |
|---|---|---|
| 1 | series-configuration.mdx:8 |
The unlayered branch says the settings on this page "are simply the chart's own settings", but the page is scoped to layers (:3, :6) and every section is an override whose global counterpart is documented elsewhere (data-labels.mdx:12, color-and-stacking.mdx#stacking-options, and :32's own hand-off for color). A reader with a two-measure query and no layers is told the page applies to them, then meets ## Mark type override — the per-series thing the paragraph just denied them. |
Suggested wording is in the inline comment. Low severity — a scoping claim, not a wrong instruction, and the fix is to point at the global pages rather than absorb them.
Verification
The chart builder isn't in this repo, so whether an unlayered multi-series chart has any per-series surface remains on the author's word. Internal consistency is what I checked:
data-labels.mdx:12andcolor-and-stacking.mdx:56do own the global versions of two of this page's four sections, which is what the finding turns on.color-and-stacking.mdx:54andseries-mapping.mdx:38still state the palette-by-position rule in the same terms, both scoped to the pinned-Series case.- The walkthrough at
:22-26starts at + Y Axis, so it sits in the layered branch and is unaffected. bar.mdx:44andline.mdx:42both still start the composite recipe at + Y Axis;charts/index.mdx:33andcharts/configuration/index.mdx:11both describe this page as per-Y-axis-layer and neither promises per-series color.custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Smaller notes (not worth blocking)
series-mapping.mdx:34— "Layers are also what carry per-series mark types" says per-series for what the last two commits established as per-layer. Harmless when a layer holds one measure, ambiguous when it folds.series-configuration.mdx:16,36,40,42,48andaxes.mdx:39,bar.mdx:60,color-and-stacking.mdx:72— all still say "series" for the thing that carries settings, which this PR standardized on "layer". Cosmetic, but it's the vocabulary split that made rounds 5–12 ambiguous; a sweep would retire it for good.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from nine rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 1 addition / 1 deletion in one existing page in this commit, no code, config, or docs.json navigation changes.
…tead of the override sections
|
Claude finished @igorlukanin's task in 1m 42s —— View job Re-review after
|
| Was | Now |
|---|---|
series-configuration.mdx:8 said that on an unlayered chart the settings on this page "are simply the chart's own settings", which folded this page's overrides into the global ones and left :6's layer scope contradicted |
The sentence now points outward instead of absorbing: "With no layers there is nothing to override, so a multi-series chart is configured by the global settings instead — [data labels], [stacking, and color]. Add a layer and the sections below become available to it." |
That is the right direction: the three links land on the pages that actually own those settings (data-labels.mdx:12 for the Fields-tab Data Labels toggle, color-and-stacking.mdx Stacking options and Mark color), and "Add a layer and the sections below become available to it" keeps :6's scope intact rather than widening the page.
New finding
| # | File | Issue |
|---|---|---|
| 1 | series-configuration.mdx:8 |
"the global settings instead" substitutes for "the sections below", but only two of this page's four sections have a counterpart in the list. Mark type override (:12) and Y axis assignment (:34) have none — so whether those two move or simply don't exist without layers is left to inference, and axes.mdx:38 routes the right axis through "the Series configuration for a specific series", which is a layer under the new model. |
Suggested wording is in the inline comment. Low severity — an omission in an enumeration, not a wrong instruction.
Verification
The chart builder isn't in this repo, so whether an unlayered multi-series chart really has no per-series surface remains on the author's word. Internal consistency is what I checked:
- Both new links resolve:
data-labels.mdxandcolor-and-stacking.mdxexist, and each owns the global version of the setting the sentence hands to it.color-and-stacking.mdx:49-53(Mark color) already scopes the swatch away from multi-series mode, agreeing with:32's pointer here. - The walkthrough at
:22-26starts at + Y Axis, so it sits in the layered branch and is unaffected by this edit. series-mapping.mdx:38andcolor-and-stacking.mdx:54still state the palette-by-position rule in the same terms.bar.mdx:44andline.mdx:42both still start the composite recipe at + Y Axis;charts/index.mdx:33andcharts/configuration/index.mdx:11both describe this page as per-Y-axis-layer and neither promises per-series color.custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Smaller notes (not worth blocking)
:8—[stacking, and color]puts the list's serial comma inside the link text, so the link reads as one item named "stacking, and color".[stacking](…#stacking-options) and [color](…#mark-color)would also deep-link to the two sections.series-mapping.mdx:34— "Layers are also what carry per-series mark types" says per-series for what the last three commits established as per-layer.series-configuration.mdx:16,36,40,42,48andaxes.mdx:39,bar.mdx:60,color-and-stacking.mdx:72— all still say "series" for the thing that carries settings, which this PR standardized on "layer". Cosmetic, but it's the vocabulary split that made rounds 5–13 ambiguous; a sweep would retire it for good.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from ten rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 1 addition / 1 deletion in one existing page in this commit, no code, config, or docs.json navigation changes.
…mdx through + Y Axis
|
Claude finished @igorlukanin's task in 2m 12s —— View job Re-review after
|
| Was | Now |
|---|---|
series-configuration.mdx:8 handed the unlayered case to "the global settings", but only two of the page's four settings had a counterpart in that list — Mark type override and Y axis assignment had none, and axes.mdx:38 routed the right axis through "the Series configuration for a specific series", which is a layer under the new model |
:8 now splits the four: data labels, stacking, and color "come from the global [data labels] and [color & stacking] settings", while "mark type and axis assignment do not apply at all — every series is drawn with the chart's own mark, on its one Y axis." axes.mdx:39 starts the dual-axis recipe at + Y Axis and links to the layer page, so an unlayered chart is no longer sent to a control it can't reach. |
Answering the two settings that don't move with "they don't exist without a layer" is the right cut — it keeps :6's layer scope intact instead of inventing a global counterpart, and it makes axes.mdx's prerequisite explicit at the top of the recipe rather than leaving it implied by the word "series".
New finding
| # | File | Issue |
|---|---|---|
| 1 | series-configuration.mdx:8 |
"Add a layer and all four sections below become available to it" — there are five H2s below (Mark type override, Color, Y axis assignment, Data labels per series, Stacking override), and Color is the one that isn't per-layer per :32. A reader who counts finds five and has to infer which four. |
Suggested wording is in the inline comment — naming the four settings instead of counting sections also stops the sentence from breaking if a section is ever added.
Verification
The chart builder isn't in this repo, so whether an unlayered multi-series chart really has no mark-type or axis control remains on the author's word. Internal consistency is what I checked:
axes.mdx:39andseries-configuration.mdx:26,34-38now agree on the order of operations: layer first, then Left/Right.bar.mdx:44andline.mdx:42both already started at + Y Axis, so all four dual-axis instructions in the docs match.- Repo-wide, nothing routes axis assignment or mark type through anything but a layer any more — the remaining
Y-axis seriesphrasings (series-configuration.mdx:48,color-and-stacking.mdx:72,bar.mdx:60) are all about stacking, which is genuinely per-layer, and none of them contradicts the new rule. series-mapping.mdx:34andseries-configuration.mdx:8still state the layer/fold relationship in the same terms ("a repeat of the whole set of Fields controls", "the rule above applies inside each one separately").custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Smaller notes (not worth blocking)
series-configuration.mdx:36— "For charts with a dual Y axis, assign each series to either the Left or Right Y axis" reads as if the second axis pre-exists, whileaxes.mdx:39says assigning a layer to Right is what creates it. The two are circular rather than contradictory; one of them could say which comes first.axes.mdx:39— step 1 now contains two actions ("press + Y Axis … then change its Y axis assignment"). Splitting them would keep the list one-action-per-step, as it was before.series-mapping.mdx:36,40— "While the chart is in this multi-series mode" and the exit instruction still say chart, but per:34the fold is per layer. Carried over.series-configuration.mdx:14,42,48,bar.mdx:60,color-and-stacking.mdx:72— all still say "series" for the thing that carries settings, which this PR standardized on "layer". Cosmetic, but it's the vocabulary split that made rounds 5–14 ambiguous; a sweep would retire it for good.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from eleven rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 2 additions / 2 deletions across 2 existing pages in this commit, no code, config, or docs.json navigation changes.
|
Claude finished @igorlukanin's task in 1m 23s —— View job Re-review after
|
| Was | Now |
|---|---|
series-configuration.mdx:8 said "Add a layer and all four sections below become available to it", but there are five H2s below and Color is the one that isn't per-layer (:32) — a reader who counts finds five and has to infer which four |
:8 now names them: "Add a layer and it gets its own mark type, Y axis assignment, data labels, and stacking." Those are exactly the four per-layer sections (:12, :34, :40, :46), in section order, and Color is left out by omission rather than by arithmetic. |
Naming instead of counting also makes the sentence robust to a section being added later, which was the reason for suggesting it.
Verification
The chart builder isn't in this repo, so which settings a layer actually carries remains on the author's word. Internal consistency is what I checked:
- The four named settings map 1:1 onto the page's per-layer H2s, and the fifth (Color) is consistent with
:32's hand-off and withcolor-and-stacking.mdx:49-54. - The preceding clause's global-settings list (data labels, stacking, color) still resolves —
data-labels.mdx:12owns the Fields-tab Data Labels toggle,color-and-stacking.mdxowns stacking and mark color — and the two settings said not to exist without a layer (mark type, axis assignment) are the two absent from that list, so the enumeration is complete in both directions. axes.mdx:39still starts the dual-axis recipe at + Y Axis, andbar.mdx:44/line.mdx:42still give the same three steps for the composite recipe.series-mapping.mdx:34andseries-configuration.mdx:8still state the layer/fold relationship in the same terms.custom-roles.mdxis untouched by this commit; its two tables still match theRoleWithAccess.actionsenum inapi-reference/api.yaml:7786-7814.docs.jsonis untouched, and no page links to a heading renamed in this PR.
Nothing new surfaced. As far as I can tell the correctness pass is complete — every claim this PR touches now has exactly one statement in the docs, and the pages that reference it agree with that statement.
Smaller notes (not worth blocking)
series-configuration.mdx:16,36,40,42,48,color-and-stacking.mdx:54,72,bar.mdx:60— all still say "series" for the thing that carries settings, which this PR standardized on "layer" (## Data labels per series, "assign each series to either Left or Right", "expand the Y-axis settings for a specific series"). Cosmetic, and it's the vocabulary split that made rounds 5–15 ambiguous; a rename sweep would retire it for good.series-configuration.mdx:36vsaxes.mdx:39— "For charts with a dual Y axis, assign each series to …" reads as if the second axis pre-exists, whileaxes.mdxsays assigning a layer to Right is what creates it. Circular rather than contradictory. Carried over.series-configuration.mdx:42— "Configure label position, font, and format independently for each series" is a per-layer claim, butdata-labels.mdx:6describes the global feature as a total above each full stack, which is a chart-level aggregate. Pre-existing; flagging only because the two now sit one link apart.series-mapping.mdx:36,40— "While the chart is in this multi-series mode" and the exit instruction still say chart, but per:34the fold is per layer. Carried over.scatter.mdx:24enumerates the Fields tab as "X, Y, Color, tooltips, data labels, and small multiples", but the channel table inseries-mapping.mdxhas no data labels row. Carried over from twelve rounds ago.
Non-applicable review dimensions
Security, performance, and test coverage don't apply — docs-only, 1 addition / 1 deletion in one existing page in this commit, no code, config, or docs.json navigation changes.
1 participant
Corrects documentation that does not match what the product does.
Series mapping
The page described a drag-and-drop model the chart builder does not have. Every encoding channel is a dropdown (
ChannelControlsSectionrenders aSelect), there is no "Available fields" list anywhere in the app, and there is no field token to drag out of a slot. Four claims were affected:The two screenshot placeholders on the page were rewritten to describe the UI that actually exists.
Tooltips
The same drag-and-drop model was stated verbatim on the tooltips page, and was wrong in a further two ways.
TooltipFieldsSectionrenders one row per field — aSelectplus an × — behind a + Tooltip button, so there is no reordering at all. Disabling is the switch on the section header, and re-enabling restores the automatic tooltip rather than the field list that was configured.Scatter and map
Both pages documented a Size channel. They are not the same case:
encoding.sizeis read byVegaStyleBuilderto show a legend section, but no Fields-tab control ever writes it, so size is reachable only through the Vega spec editor. The page now says that.MapChartBuilder— so the channel stays. Only its claim of a configurable minimum/maximum radius was removed; the real controls are Default size and Custom size.Custom roles
actionsWithoutDeveloperRequirementexempts three:DeploymentRead,DeploymentAgentRead, andDownloadData. Reworded to name all three, which the Tip below it already did forDeploymentAgentRead.SqlRunnerRead,DeploymentAgentRead, andPreAggregationBuild— while the reference catalog opens with "every action a custom role can grant". All ten are now in both tables, in the builder's group order.APMRead, not exempt, so the role would jump to Developer and disable the Explorer option chosen two steps earlier. Corrected the step.