* Fix LgeacyMetric/Segment macroexpansion with definitions using ancient MBQL 2

* Remove stray println

* PR feedback

* Window functions should use all breakouts except first for partitioning

* Update the offset() test

* Update tests

* Rework how we use driver escape-alias in MLv2; fix Oracle

* PR feedback

* Test fixes 

This is a new parameter `:type` (and `:widget-type`) to choose a time
granularity (a `:temporal-unit`, eg. `month`, `day`, `day-of-week`)
which should replace the unit on the target field for the parameter.

The target field should be a breakout with a temporal type (date,
datetime) that's compatible with the input unit. The value of the
parameter should be a string or keyword naming one of the units:
`"month"`, `:month`.

Part of #42118.

Optimize loading of admin permissions pages (add skip_fields flag to database metadata endpoint) (#42062)

* add skip_fields flag to database metadata endpoint

* skips loading fields on database metadata requests while on admin permissions pages

---------

Co-authored-by: Sloan Sparger <sloansparger@gmail.com>

* Add trackColumnExtractViaHeader helper

* Add Lib.extract wrapper

* Track column extractions via header

* Fix analytics event name

* Add tests for extract action analytics

* Set up extractions metadata helper

* Use functionsUseByExtraction in analytics

* Add custom type for ExtractionTag

* Use ExtractionTag in analytics

* [MBQL lib] Add `Lib.columnExtractDrillExtractions`

This gets the extractions from a column-extract drill, which is needed
in the UI.

* Add extractionExpression wrapper

* Add extractionsForDrill helper

* Fix type signature of extractionExpression

* Use expressionParts for getting expression function

* Walk expression to get functions used

* Simplify ColumnExtractionTag

* Fix expected expression

* Be more explicit with what the guard does

---------

Co-authored-by: Braden Shepherdson <braden@metabase.com>

These string matching clauses only allowed two arguments previously.
Typically `[:contains field x]` to match a field against a literal.

This adds similar desugaring for `:contains`, `:does-not-contain`,
`:starts-with` and `:ends-with` that is currently done for
multi-argument `:=` and `:!=`:

```clojure
[:contains field x y z] ;; ->
[:or [:contains field x] [:contains field y] [:contains field z]]

[:does-not-contain field x y z] ;; ->
[:and [:does-not-contain field x]
      [:does-not-contain field y]
      [:does-not-contain field z]]
```

* Fix Snowflake filtering on date for `timestamp with time zone` columns

* Snowflake should just generate raw SQL for literals

* Go ahead and fix other Snowflake stuff and reenable a bunch of disabled tests

* Snowflake test fixes 

* Minor test improvements

* Fix Redshift and Vertica as well.

* Address PR feedback

* Store Parameter Values Set by User on a per-user basis

This is a WIP for #28181 and the notion doc:

https://www.notion.so/metabase/Tech-Maintain-user-level-state-in-dashboards-for-filters-fc16909a3216482f896934dd94b54f9a

Still to do:

- [ ] validate the table/model design
- [ ] hook up the endpoints mentioned in the doc (2 in api/dashboard)
- [ ] return the user specific parameter values on /api/dashboard/:dashboardID endpoints
- [ ] write a few tests to capture the intent of this feature

* Accidentally deleted a digit in the change ID timestamp

* first pass at writing user param values to the db.

It's in a doseq here which is probably not the correct way to go yet, but it's a step in the right direction.

* Hydrate dashboard response with `:last_used_param_values` key

If the user has previously set a parameter's value, it will show up in the map under that parameter id.

If the user has no parameter value set, that entry will be 'null'.

* Use proper fn name

* Only save or retreive user params if there's a current user id

* Add model to necessary lists

* Only run query when there are parameter ids to run it with

* Add a test to confirm that last_used_param_values works

* Add models test namespace for CRUD test

* The hydration is checked in the dashboard api test already

* Revert "Store fields used in MBQL cards in QueryField (#41821)"

This reverts commit 0da81005.

* comment out test

Previously they could only be added to the query with `Lib.extract`, but
this returns the expression the extract would add.

* Fix add-alias-info matching for nominal field literal refs

* Minor cleanup

* Minimize diff

* A bit more cleanup

* Cumulative aggregations w/ multiple breakouts should reset counts (#2862)

* Update dox

* Do the nesting FIRST before adding alias info.

* Remove unused

* FE for Offset()

* Cleanup stray code

* Prettier

* Kondo

* Test fixes 

* Better error message when no breakout

* Support offset as an expression with no breakouts. Still require an ORDER BY tho.

* Fix most stuff

* Hack city??????

* Revert nest-query changes and disable the offset-no-breakout test for now.

* Appease TypeScript

* Test fix 

* Oracle & MySQL test fixes

* Test fixes 

* Remove maxWorkers for FE unit tests

* Missing sentence for NQA documentation

* Add a test for optional field filter parsing

Co-authored-by: Emmad Usmani <emmadusmani@berkeley.edu>
Co-authored-by: Adam James <adam.vermeer2@gmail.com>
Co-authored-by: Mark Bastian <markbastian@gmail.com>
Co-authored-by: Jesse Devaney <22608765+JesseSDevaney@users.noreply.github.com>
Co-authored-by: Anton Kulyk <kuliks.anton@gmail.com>

* Add `collection.effective_ancestors` to search

Fixes #41909

The ultimate goal here is to be able to display a UI that showed the entire (effective) path to each collection.

This was a bit more painful than I'd hoped. The primary issue is that we
tied two things together:

- scoring results

- "serializing" results (really, partially serializing results, because
we do more work to shape the data later)

Why is this a problem? The `top-scorers` function took a transducer and
returned the *serialized* top scorers. Later, when we need to operate
on *all* the top results (in this case, to collect all the collection
IDs and names that we know of), we're looking at the serialized results.

In our case, we needed some data (collection location) that wasn't
included after serialization. We could add it, of course, but it's
frustrating to need to change the API of what data is *returned* from
the endpoint for purely internal purposes (changing the data available
during *processing*).

I ended up pulling serialization out of the scoring function. At some
point down the road, we should go ahead and move the `serialize`
function out of the `search.scoring` namespace entirely - there's really
no reason for it to belong there as far as I can tell.

The new expressions `:month-name`, `:quarter-name` and `:day-name`
return the (user localized) names for these units, given the
corresponding number.

For example, 4 yields `"Apr"`, `"Q4"` or `"Wednesday"` respectively.

The `column-extract` drill uses these new expressions, rather than
generating its own `:case` clauses for them.

Note that `:day-of-week` and `:month-of-year` are tricky cases for i18n, but there are tests that exercise them thoroughly.

Part of the follow-up for Extract Column epic #38964.

* Fix the flake in add-required-filter-if-needed-test due to field order

* /s/oredered-filter/ordered-filter

Column extractions are "canned" expressions based on a column's
type. For example, we might extract the weekday from a temporal column,
or the domain from an email or URL column.

This logic already existed inside the `column-extract` drill; this pulls
it out as a top-level concept, since extractions are also being
integrated into the notebook editor apart from drills.

Part of the follow-up for Extract Column epic #38964.

(It's coming back in similar form, but EE-only)

This reverts commit f5bd6344.

Pretty much does what it says on the tin.

Co-authored-by: Chris Truter <crisptrutski@users.noreply.github.com>

* Dates Binned by Week Export Formatting Matches App

Fixes: #41492

Before, the dates binned by week would be formatted as follows in CSV and JSON exports:

`Week 1 - 2024`

But that doesn't match the App's format of a Date Range:

`January 1, 2024 - January 7, 2024`

So, now the exports will apply formatting in this same way.

Note that a second bug (#41616) exists on the Frontend preventing the column formatting being applied in the app. This is
frontend only, and the csv and json exports will match the column formatting settings (eg. abbreviated dates and
alternative separators will be used in the export).

* add test and change default week style

* Week format test change

* also fix incorrect :hour formatting