This project is mirrored from https://github.com/metabase/metabase.
Pull mirroring updated .
- Jun 07, 2024
-
-
metabase-bot[bot] authored
* Move role to url parameters from connection properties * Fix test Co-authored-by:
lbrdnk <lbrdnk@users.noreply.github.com>
-
metabase-bot[bot] authored
Co-authored-by:
Alexander Solovyov <alexander@solovyov.net>
-
John Swanson authored
* Correct type for `report_card.dataset` This was missed in the original migration of boolean types to ${boolean.type} in MySQL/MariaDB, and then missed again by me when I migrated `collection_preview` over a week ago. * Change all boolean types to `bit(1)` in MySQL Liquibase changed their boolean type in MySQL from `bit(1)` to `tinyint(4)` in version 4.25.1. Our JDBC driver does not recognize these as booleans, so we needed to migrate them to `bit(1)`s. As discussed [here](#36964), we changed all existing `boolean` types that were in the `001_update_migrations.yml` but not the SQL initialization file. For new installations, this works: things in the SQL initialization file get created with the `bit(1)` type. However, for existing installations, there's a potential issue. Say I'm on v42 and am upgrading to v49. In v43, a new `boolean` was added. In this case, I'll get the `boolean` from the liquibase migration rather than from the SQL initialization file, and it need to be changed to a `bit(1)`. I installed Metabase v41 with MySQL, migrated the database, and then installed Metabase v49 and migrated again. I made a list of all the columns that had the type `tinyint`: ``` mysql> SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_TYPE, COLUMN_DEFAULT, IS_NULLABLE FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_TYPE = 'tinyint' AND TABLE_SCHEMA='metabase_test'; +---------------+------------------------------+-------------------+-------------+----------------+-------------+ | TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | COLUMN_TYPE | COLUMN_DEFAULT | IS_NULLABLE | +---------------+------------------------------+-------------------+-------------+----------------+-------------+ | metabase_test | core_user | is_datasetnewb | tinyint | 1 | NO | | metabase_test | metabase_field | database_required | tinyint | 0 | NO | | metabase_test | metabase_fieldvalues | has_more_values | tinyint | 0 | YES | | metabase_test | permissions_group_membership | is_group_manager | tinyint | 0 | NO | | metabase_test | persisted_info | active | tinyint | 0 | NO | | metabase_test | report_card | dataset | tinyint | 0 | NO | | metabase_test | timeline | archived | tinyint | 0 | NO | | metabase_test | timeline | default | tinyint | 0 | NO | | metabase_test | timeline_event | archived | tinyint | 0 | NO | | metabase_test | timeline_event | time_matters | tinyint | NULL | NO | +---------------+------------------------------+-------------------+-------------+----------------+-------------+ 10 rows in set (0.01 sec) ``` Then wrote migrations. For each column, we: - turn it into a `bit(1)`, - re-set the previously existing default value, and - re-add the NOT NULL constraint, if applicable. * Change author and add missing `dbms` --------- Co-authored-by:
SakuragiYoshimasa <ysrhsp@outlook.com>
-
- Jun 06, 2024
-
-
Nemanja Glumac authored
* Add e2e reproduction for #39150 * Skip the failing repro scenario
-
Alex Yarosh authored
-
- Jun 05, 2024
-
-
metabase-bot[bot] authored
* temporarily removes the SameSite=None suggestion box * fix copy Co-authored-by:
Nicolò Pretto <info@npretto.com>
-
- Jun 04, 2024
-
-
Cal Herries authored
-
metabase-bot[bot] authored
* Update dead jetty docs link * Update dead jetty docs link Co-authored-by:
Kamil Mielnik <kamil@kamilmielnik.com>
-
- May 31, 2024
-
-
metabase-bot[bot] authored
Co-authored-by:
Sloan Sparger <sloansparger@users.noreply.github.com>
-
Noah Moss authored
-
metamben authored
Fixes #40176.
-
metamben authored
Fixes #43089.
-
- May 30, 2024
-
-
lbrdnk authored
* [Manual backport] Backfill :effective-type for coerced fields (#43144) * Remove bulk-metadata "pre-warm" call bulk-metadata implementation for metadata provider in use is not present on this branch. Hence the pre-warm call was removed. Passing of no-lazyness-test hints that should be ok. * Update test query reqires keywordized form on 49 * Fix missing every-pred
-
- May 28, 2024
-
-
Jesse Devaney authored
* fix trend charts erroring on latest value being null * refactor previousRowIndex calculation * handle errors gracefully * refactor error messages * update computeTrend unit tests * add error handling integration test * add E2E test to check that errors are gracefully handled * add integration test to enforce the fix * fix static viz * display more meaningful error on static-viz trend charts * move error handling out of trend chart and fix error handling in Visualization.tsx * update compute.unit.spec.js * update SmartScalar.unit.spec.js * use separate error handler for ErrorBoundary errors in Visualization.jsx * update E2E test * update error handling * update compute.unit.spec.js * fix react state change error in render function * show generic error message for ErrorBoundary caught errors * revert ErrorBoundary changes * remove generic error border for visualizations
-
bryan authored
-
Alexander Solovyov authored
-
- May 27, 2024
-
-
metabase-bot[bot] authored
Co-authored-by:
Alexander Solovyov <alexander@solovyov.net>
-
- May 23, 2024
-
-
metabase-bot[bot] authored
Co-authored-by:
Cal Herries <39073188+calherries@users.noreply.github.com>
-
- May 21, 2024
-
-
John Swanson authored
This is a bit painful. I merged this change, but realized we need to backport the fix to v49. However: - we don't want to have two versions of the migration (one with a v49 id, one with a v50 id) because then if someone upgrades to 50, then downgrades to 49, the `rollback` will run and change the type back, leading to a bug. - we don't want to push a v51 changeSet ID to v49 or v50, because we give the user a helpful notice when their database needs a downgrade. We do this by checking for the latest *executed* migration in the database and comparing it to the latest migration that Liquibase knows about, and making sure the executed isn't bigger than the known (e.g. you can't have executed a v51 migration if it isn't in the local migration yaml). That would all work fine, except that then we want to tell you how to downgrade your database, and we use the latest-executed version for that. So if, for example, someone upgraded from 48 to 49 and got a v51 changeset, then downgraded back to 48, they would get an error telling them to run the *v51* jar to roll back their DB. In this case though, I think it's fine to just move the migration around to v49, then we can backport it to 49 and 50.
-
- May 20, 2024
-
-
metabase-bot[bot] authored
Co-authored-by:
Nicolò Pretto <info@npretto.com>
-
- May 17, 2024
-
-
metabase-bot[bot] authored
Co-authored-by:
Cal Herries <39073188+calherries@users.noreply.github.com>
-
- May 16, 2024
-
-
metabase-bot[bot] authored
Co-authored-by:
Alexander Polyankin <alexander.polyankin@metabase.com>
-
metabase-bot[bot] authored
Co-authored-by:
Alexander Polyankin <alexander.polyankin@metabase.com>
-
metabase-bot[bot] authored
Co-authored-by:
Jeff Bruemmer <jeff.bruemmer@gmail.com>
-
metabase-bot[bot] authored
Co-authored-by:
John Swanson <john.swanson@metabase.com>
-
metabase-bot[bot] authored
Co-authored-by:
Alexander Polyankin <alexander.polyankin@metabase.com>
-
metabase-bot[bot] authored
* 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. Co-authored-by:
John Swanson <john.swanson@metabase.com>
-
metabase-bot[bot] authored
3 TODOs were removed here: - "a way to SET Database-local values." More like TODONE :haaa: - "we should probably also bind this [that is, *database-local-values*] in sync contexts e.g. functions in [[metabase.sync]]" I think we don't need to do this. The full set of maybe-database-local settings right now is `aggregated-query-row-limit`, `unaggregated-query-row-limit`, `database-enable-actions`, and `persist-models-enabled`. None of these need to be set when `sync`ing. If at some point we do add a db-local setting that should affect the way syncing works, we will need to do this - but I don't think this TODO will help figure that out. - "settings sent via an env var aren't returned for security purposes. It is an open question whether we should obfuscate them and still show the last two characters like we do for sensitive values that are set via the UI." I think if it's been this way for 5 years, it no longer qualifies as an "open question." We can reopen if down the road if this is something we want. Co-authored-by:
John Swanson <john.swanson@metabase.com>
-
metabase-bot[bot] authored
Co-authored-by:
Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev>
-
metabase-bot[bot] authored
backported "Realize DB transient rows in after-select hook before calling `driver.u/features`" (#42745) * Realize DB transient rows in after-select hook before calling `driver.u/features` (#42744) --------- Co-authored-by:Cal Herries <39073188+calherries@users.noreply.github.com> Co-authored-by:
Ngoc Khuat <qn.khuat@gmail.com>
-
- May 15, 2024
-
-
metabase-bot[bot] authored
* update collections * feedback * links * Update docs/questions/native-editor/sql-parameters.md --------- Co-authored-by:
Alex Yarosh <alexandra@metabase.com> Co-authored-by:
Jeff Bruemmer <jeff.bruemmer@gmail.com>
-
metabase-bot[bot] authored
this lowers memory usage 100x for 50kb strings (our limit before this change) and speeds up parsing by an order of magnitude. For example, results for parsing 42kb string (already in memory): Before: Time per call: 6.32 ms Alloc per call: 8,732,850b After: Time per call: 55.16 us Alloc per call: 83,254b
-
metabase-bot[bot] authored
Co-authored-by:
Ngoc Khuat <qn.khuat@gmail.com>
-
- May 14, 2024
-
-
metabase-bot[bot] authored
-
Cal Herries authored
-
- May 13, 2024
-
-
metabase-bot[bot] authored
* Don't use the slugify util for filenames * Fix tests that looked for incorrect filenames * add a test * fix filename in pulse test util Co-authored-by:
adam-james <21064735+adam-james-v@users.noreply.github.com>
-
metabase-bot[bot] authored
Co-authored-by:
Jeff Bruemmer <jeff.bruemmer@gmail.com>
-
metabase-bot[bot] authored
Co-authored-by:
Noah Moss <32746338+noahmoss@users.noreply.github.com>
-
- May 10, 2024
-
-
metabase-bot[bot] authored
* Format Rows toggle also applies to Column Names Fixes: #42500 When format-rows is false, we want to also pass that true/false value to the title column formatting. That is, if a column is renamed and formatting is applied, we want to use that column's name. But, if a column is renamed and the user exports unformatted csv or json, the custom column name should NOT be used, as was the behaviour in prior versions. * write a better test explanation Co-authored-by:
adam-james <21064735+adam-james-v@users.noreply.github.com>
-
metabase-bot[bot] authored
* fix pie chart display when switching from notebook editor * remove hack * fix missing pie chart display * fix missing pie chart display * address feedback * fix type error Co-authored-by:
Jesse Devaney <22608765+JesseSDevaney@users.noreply.github.com>
-