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.

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.

Also add the replace-names fn, which is a simple pass-through to Macaw #modularity

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

This reverts commit f5bd6344.

Pretty much does what it says on the tin.

It has a slightly different API shape. We're not using it right this
minute, but we're about to and it seemed nice to separate this out into
its own PR

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

* [tech debt] Stop using ms/BooleanString and only use ms/BooleanValue

ms/BooleanString will coerce to a string, and we should probably get rid of it and only ever use ms/BooleanValue which will always coerce to a boolean
We want the coercion layer to give us values that are helpful, and true is more helpful than "true".
So we should remove ms/BooleanString and calls to parseBoolean

* Remove ms/BooleanString usage in api/native_query_snippet.clj

* Remove test case related to ms/BooleanString

* Remove the BooleanString schema def as no longer used

These functions are implemented with hairy regular expressions, and
it's more user-friendly and future-proof to name those functions in MBQL
rather than baking the `regexextract` and regex into the user's query.

It lets us evolve the regexes in the future if we detect a bug, and it
improves the UX since the user sees a meaningful function instead of

    regexextract([My URL Column], "(?<=[@\.])(?!www\.)[^@\.]+(?=\.[^@\.]{1,3}\.[^@\.]+$|\.[^@\.]+$)")

Also refactors the regexes somewhat so that they work for emails as well as URLs, and there's always just one layer of `:regex-match-first`.
Previously this was separated into two steps: URL or email to host, and host to (sub)domain.

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

Co-authored-by: Noah Moss <noahbmoss@gmail.com>
Co-authored-by: Noah Moss <32746338+noahmoss@users.noreply.github.com>
Co-authored-by: Nick Fitzpatrick <nick@metabase.com>
Co-authored-by: John Swanson <john.swanson@metabase.com>
Co-authored-by: Sloan Sparger <sloansparger@users.noreply.github.com>
Co-authored-by: Sloan Sparger <sloansparger@gmail.com>

When we actually run the job to cache models, we select "refreshable
models", which selects `PersistedInfo` where:

- the `state` is something refreshable, and

- the question marked for caching is actually a model, and

- the question hasn't been archived.

However, when we selected `PersistedInfo`s to display to the user, we
didn't apply any conditions. Instead, we included PersistedInfo where
the question was not a model, or where the question had been archived.

To prevent confusion, let's hide these.

Fixes https://github.com/metabase/metabase/issues/41318

The filters for _numeric_ PK and FK filters are slightly different than a general numeric column. That's fine for numeric keys, but with string keys that same set of numeric filters was being returned, and then the ones for strings were removed. That left only `Is` and `Is Not` for a string PK or FK.

This PR allows more flexibility in filtering by string PKs and FKs, by checking the base type of the column and using the right set of filters for the type of key.

Closes #40665.

* FeedbackModal for the Embedding Homepage

* add source and change to correct endpoint

* fix tests, adding await and fixing endpoint

* use toEqual to also check for the source

* addresses PR feedback

* button becomes Send when email is written

* make 'comments' optional, trim inputs and refactor tests

* product-feedback endpoint (#40974)

* mvp of the proxy endpoint for the product feedback

* cleanup and fixes

* email :string -> ms/NonBlankString

* revert my solution

* Dan diff file

* makes fields other than source optional

* don't use default value in dev, to not spam the prod endpoint

* change from setting to function for product-feedback-url, as it's not meant to be changed by end users

* changed endpoint as per https://metaboat.slack.com/archives/C010ZSXQY87/p1712918951362979?thread_ts=1704910781.153589&cid=C010ZSXQY87



* fix wrong dismiss reason sent for 'I'm not interested right now'

* Update frontend/src/metabase/home/components/EmbedHomepage/EmbedHomepage.tsx

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

* renamed field: feedback -> comment

---------

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

This reverts commit e0e4ade0.

* Cancel statement on completion of execute-reducible-query

* Address review remarks