* docs: JWT groups with env vars

* typo

* Add metrics to table pane

* Add test for metric in data reference sidebar

* Clean up other reference tests

* Add test for when the table has no metrics

* Use helper for sidebar header title

* Rename sidebar to create distinction from existing helper

* fix(sdk): modal pushing content below when opened

* render the portal below the content so we don't need the zIndex

Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev>

---------

Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev>

* add eslint plugin for storybook

* fixup

* fixup

* fixup

* Add 'New metric' action to command palette

* Add test for 'New metric' in command palette

* Simplify browse components imports

* Move metrics-related browse components to separate folder

* Move models related browse components to separate subdir

* Split up browse/test-utils

* Move schemas related browse code to separate folder

* Move databases related browse code to separate folder

* Move tables related browse code to separate folder

* Fix import paths

* Avoid drilling into metric module

* Avoid drilling into models module

* Move enterprise tests for browse models

* Format comments

* Remove unused sortModelsByVerification plugin helper

* Support skipToken in useFetchModels

* Simplify models content verification

* Fix filter button query

* Do not filter recent models if there are no verified models

* Use filterButton helper everywhere

* Fixup comment

* Use new var-style color

* Await dashcard query when editing

* Reload to fix flake

* Reset filters to fix flake

* Await dashcard query when editing

* Wait for query

* WIP

* Hard-visit dashboard

* Split up test to avoid navigation issues

* Allow using metrics with offset in custom expressions

* Unskip and update repro

* Do not cache all token check failures

We want to cache token checks to avoid an issue where we repeatedly ask
the store "hey, is this token valid?? is this token valid?? is this
token valid??" for the same token.

However, transient errors can also occur. For example, maybe a network
issue causes the HTTP request to fail entirely. In this case, if we
cache the result, the user needs to restart metabase (or wait 5 minutes
until the cache is cleared) before they can attempt to validate their
token again.

This PR moves the cache logic deeper into the stack. We want to cache
"successful" responses from the store API - cases where the store has
told us categorically that the token is or is not valid. We don't want
or need to cache other things that might happen. Maybe your token isn't
the right length - we can recalculate that, it's ok. Maybe you get a 503
error from the Store - we should let you retry. Maybe your network is
having issues and you can't contact the Store at all - again, we should
let you retry.

The one potential issue I see here is that if the store goes down, we'll
massively increase the number of requests we send to the store,
potentially making it harder to recover. If this is a concern, I can add
a circuit breaker: if we repeatedly get errors back from the store, back
off and stop making requests for a while.

* Add a circuit breaker to store API requests

In the pathological case where the store goes down for >5 minutes, the
cache will expire and all instances everywhere will start repeatedly
making requests for token validation at once. This might make recovering
from an outage more difficult.

This adds a circuit breaker around the API request. If the call
repeatedly throws (5XX errors, socket timeouts, etc.) then we'll pause
for 1 minute, during which time all calls to token validation will
immediately fail without making any request to the API.

After one minute, we'll allow one request through to the API. If it
succeeds, we'll go back to normal operation. Otherwise, we'll wait
another minute.

* putSetting helper

* change all usages of cy.request("PUT" "api/setting/..." to putSetting(...) in e2e tests

* Update e2e/support/helpers/api/putSetting.ts

Co-authored-by: Kamil Mielnik <kamil@kamilmielnik.com>

* Update e2e/support/helpers/api/putSetting.ts

Co-authored-by: Kamil Mielnik <kamil@kamilmielnik.com>

* sort exports

* putSetting -> updateSetting as per PR suggestion

---------

Co-authored-by: Kamil Mielnik <kamil@kamilmielnik.com>

* Temporarily disable compare to the past ui components

* Temporarily disable compare to the past tests

* Skip Compare to past unit tests

* rename usage analytics and few fixes

* update e2e tests

* update some other strings too

---------

Co-authored-by: Ryan Laurie <iethree@gmail.com>

* refactor: rework stories from MDX to MDX + CSF

* short syntax

* fix or bypass typescript errors

* fix leftovers

* cleanup leftovers

* convert js stories to tsx

* restore some comments

* fix linting

This was old logic to support certain drivers (eg. pre-JDBC Druid) and
isn't required for most. It's perfectly sound to filter or even break
out on a datetime column without bucketing.

Adds a new `:temporal/requires-default-unit` driver feature, and enables it only for the legacy Druid driver.

Fixes #47341

* Reset the dashboard parameter when setting the default value

* Fix test for filter default

* Add test for setting parameters when editing the defaults

* Use plain dispatch

Co-authored-by: Uladzimir Havenchyk <125459446+uladzimirdev@users.noreply.github.com>

* Use cy.log instead of comments

* Use icon selector

---------

Co-authored-by: Uladzimir Havenchyk <125459446+uladzimirdev@users.noreply.github.com>

Fixes 46575

Creating a Pivot Table Question that is based off of a model that has at least one column derived from a join failed
to display row totals.

This is because the pivot-options map was being mis-calculated; not all column indices were correctly found/passed in
to the :pivot-rows or :pivot-cols keys, causing the pivot query not to compute all necessary data.

Here, I just modify the :lib/source key of the columns whose source is a card (as determined by the existence of
:lib/card-id). The columns being checked will all have :source/breakout, which caused, in the issue's repro example,
the "NAME" column to be missed. If it instead has :lib/source :source/card, the logic inside
`lib/find-matching-column` works.