[pull] master from cube-js:master - #660
Merged
Merged
Conversation
β¦11533) * docs: document time zones β account policy, personal, dashboard, and embed CUB-852 shipped a tenant-wide time-zone policy with a personal override and embed overrides, and CUB-3751 then gave a dashboard and a saved exploration a zone of their own. None of it had a doc home. Two new pages, because the topic genuinely had none β settings on the Admin β Settings page are documented on their feature page, and there is no such page for time zones: - `admin/time-zones` β the authoritative one: what a zone actually changes (bucketing, relative dates, filter boundaries), the three admin controls, the personal zone, a dashboard's three choices and when a reader may borrow another zone, the exploration zone, the full resolution order, and why bare UTC offsets are rejected. - `embedding/iframe/time-zones` β mirrors the existing localization page, whose shape this feature repeats exactly: account default, `?timezone=`, and a runtime `cube:action:set-timezone`. Plus four surgical edits: a Time zone row and section on the Preferences page, `cube:action:set-timezone` in the events reference, a note that CUBEJS_DEFAULT_TIMEZONE is now the fallback rather than the only answer, and a cross-link from the Core Data APIs time-zone section. Written against the shipped code rather than the tickets, which corrected one thing: the embed zone is account-wide at Admin β Embed β Settings, not per-embed-tenant as CUB-3754 describes. * docs: use the existing time-zone terms, and say what a viewer-resolved embed does Review feedback on #11533, all five threads. The invented term went out. "Account Time Zone" is what the console UI calls it, but these docs already document that setting as **Default time zone** backed by CUBEJS_DEFAULT_TIMEZONE β so a second capitalized name meant a reader searching for it landed only on the three new pages. Worse, the docs taxonomy puts Account ABOVE Deployment, so "the deployment's Account Time Zone" read as a contradiction on a page that also documents a genuinely account-scoped zone. All 11 uses across the three pages now say "the deployment's default time zone", first use per page linked to the existing section. "Tenant" is likewise not a docs term (it appears elsewhere only inside example hostnames). It survives in exactly one place β the verbatim UI label in the controls table β with a line under the table reconciling the label with the scope name the docs use. Prose everywhere else says account-wide zone. The embed page gained the two things it was missing: a plan-availability Note, and an answer to "what does Viewer time zone mean when the viewer has no Cube account?" In signed embedding it has none, so a viewer-resolved dashboard falls through to the account default β supply ?timezone= if you want each end user's own zone. That follows from the resolver: the personal zone is only consulted for mode 'viewer', and an absent one falls through to what the artifact inherits. Also moved the Preferences Time zone section below Language so section order matches the table above it. On the plan Note: I added it to the EMBED page only. Both sibling pages that carry one agree on a Premium floor, and iframe embedding is the gated surface, so "Premium and above plans" (the phrasing CLAUDE.md prescribes) is safe there. The admin page still has none β I found no plan or feature-flag gate for the policy itself, and guessing a tier is worse than omitting it. Note the group is not uniform: 4 of the 7 iframe pages carry no plan note at all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? π Please sponsor : )