Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/metabase/metabase. Pull mirroring updated .
  1. Sep 24, 2024
  2. Sep 03, 2024
    • John Swanson's avatar
      backported "Much better collection permission performance" (#47251) (#47395) · 59ee4278
      John Swanson authored
      Backports:
      - https://github.com/metabase/metabase/pull/47398
      - https://github.com/metabase/metabase/pull/47251 (which was a backport of https://github.com/metabase/metabase/pull/46942)
      
      - removed all support for getting the trash collection, getting things
      that were `archived_directly`, or getting collections by
      `archive_operation_id`. None of these exist in this branch.
      
      - in this branch, functions like
      `permissions-set->visible-collection-ids` did not check for archived
      status or anything other than permissions. On `master`, they do. So, the
      new function that replaced them,
      `collection/visible-collection-filter-clause`, also checks for archived
      status as well as permissions. To resolve this, I chose to just default
      `collection/visible-collection-filter-clause` to ignore archived status
      and return both archived and unarchived collections.
      
      On to the original commit message:
      
      There are a few separate changes here:
      
      - Migrations: add and populate indexed columns perm_value, perm_type, and collection_id to permissions
      
      These fields allows us to efficiently run queries based on collection permissions in the DB without string manipulation. Keeping the table as permissions allows us to do this migration in-place. Note that in some cases collections may have been deleted from the database without deleting the associated permissions row (since there was no foreign key before). We need to be defensive here: if we have a permissions row without a corresponding collection, delete the row before running the rest of the migration.
      
      - Write perm_value, perm_type, and collection_id for new collection permissions
      
      A very simple before-insert method sets these fields before a collection permission is written to the DB.
      
      - Replace collection/permissions-set->visible-collection-ids and collection/visible-collection-ids->honeysql-filter-clause with collection/honeysql-filter-clause
      
      Previously, just about everywhere we used permissions-set->visible-collection-ids, what we were essentially doing was an in-app join: select all the collection IDs you have permission on, then convert it to a SQL clause like WHERE collection_id IN ( all of those collection IDs).
      
      Replace both of these with honeysql-filter-clause, which uses the new fields we added to permissions above to construct a honeysql filter representing "all the collections I have permissions on", without needing to round-trip them to the application and back to the DB.
      
      Of course, we can then write a function visible-collection-ids, which uses honeysql-filter-clause, for those cases where we do actually need the whole bunch in the application (we use this, for example, when constructing the effective-location for a collection).
      
      I also added one more toggle to the VisibilityConfig that's passed into the honeysql-filter-clause (and used to be passed to permissions-set->visible-collection-ids), allowing you to select only the effective children of some collection.
      
      * Backport: Speed up calculation of effective_ancestors
      
      https://github.com/metabase/metabase/pull/47324
      
      Previously, `visible-collection-ids` was effectively "free" in that we'd
      cached `collection-id->collection` for *all* collections, within a
      single request, and then locally filtered it for permissions without
      needing to hit the database again.
      
      To be honest, there is probably a better fix for this - we're repeatedly
      calling `visible-collection-ids` when we probably could just save a
      single copy of it and use it when calculating the effective location of
      every collection.
      
      However, this is a very quick and low-risk fix, and I want to prioritize
      getting this done, and then we can improve it later.
      
      Locally, I copied down the database from stats and timed the
      `/api/search?model_ancestors=true` endpoint.
      
      Before my "speedup" PR (https://github.com/metabase/metabase/pull/46942)
      it took ~7 seconds to return results.
      
      After my "speedup" PR, it took ~15s to return results. :grimace:
      
      With this change, it takes 818ms to return results. :tada:
      
      ---------
  3. Aug 30, 2024
  4. Aug 27, 2024
  5. Aug 19, 2024
    • bryan's avatar
      :robot: Manual backport: "Single Log Out saml-slo-enabled defsetting" to 49 (#46987) · 2708eca0
      bryan authored
      [O*] Single Log Out saml-slo-enabled defsetting (#44794)
      
      - backport:
        - use `client/client-real-response`, instead of `client-full-response`
      
      * stop using strings for enum values (prefer kw)
      
      * only do SLO when saml-slo-enabled is true
      
      * make defsetting docstring formatting consistent
      
      * log-direction is a string
      
      * add test for enabling / disabling saml slo
      
      - also return a 403 when the client tries, but it's disabled
      
      * use client-full-response, which won't add '/api'.
      
      * fix typo in deftest name
      
      ---------
  6. Aug 16, 2024
  7. Aug 13, 2024
  8. Aug 08, 2024
  9. Aug 06, 2024
  10. Aug 05, 2024
  11. Jul 31, 2024
    • Ryan Laurie's avatar
      :cherries: Manual Backport: Run without Replay (#45799) (#46305) · 04c81905
      Ryan Laurie authored
      * ci: Run without Replay (#45799)
      
      * Uninstall ReplayIO
      
      * Remove Replay config
      
      * Install and use custom Chrome v111
      
      * Simplify comment
      
      * Set a specific Chrome version commit
      
      * Skip repro for #22517
      # Conflicts:
      #	.github/actions/prepare-cypress/action.yml
      #	.github/workflows/e2e-stress-test-flake-fix.yml
      #	.github/workflows/e2e-tests.yml
      #	.github/workflows/pre-release.yml
      #	e2e/support/config.js
      #	e2e/support/cypress.js
      #	e2e/test/scenarios/models/reproductions.cy.spec.js
      #	package.json
      #	yarn.lock
      
      * sort out download utils
      
      * fix another import
    • Ngoc Khuat's avatar
      [Manual backport 49] Fix sync indexes mark all fields with same name as... · f7103f1b
      Ngoc Khuat authored
      [Manual backport 49] Fix sync indexes mark all fields with same name as indexed if one of them is (#46316)
      
      * Fix sync indexes mark all fields with same name as indexed if one of them is (#46313)
      
      * not the lib.match
  12. Jul 30, 2024
  13. Jul 29, 2024
  14. Jul 24, 2024
    • Ryan Laurie's avatar
      Fix Analytics DB Appearing in Permissions and SQL Editor (#45957) · 1935be0e
      Ryan Laurie authored
      * don't show audit db in permissions
      
      # Conflicts:
      #	enterprise/frontend/src/metabase-enterprise/audit_app/index.js
      #	frontend/src/metabase-types/api/database.ts
      #	frontend/src/metabase/admin/permissions/selectors/data-permissions/data-sidebar.ts
      #	frontend/src/metabase/plugins/index.ts
      
      * special v49 treatment
      
      * fix test for v49
      
      * add e2e tests for 45831
      
      # Conflicts:
      #	e2e/test/scenarios/collections/instance-analytics.cy.spec.js
  15. Jul 15, 2024
  16. Jul 11, 2024
    • John Swanson's avatar
      Make import work on a fresh install (#45297) (#45390) · e777280f
      John Swanson authored
      This introduces a new metadata on commands, `:requires-init`. If set,
      we'll run `metabase.core/init!` before running the command. `init!` will
      initialize the database and run our normal startup, though it won't
      actually start the Metabase server.
      
      This allows you to use
      
      ```
      env MB_CONFIG_FILE_PATH=... java -jar metabase.jar import /my/metabase/export
      ```
      
      We'll run the normal init process (creating the internal user, loading
      from the config file, etc), then run the command.
      
      On my machine this adds about 2-3 seconds to the time it takes to run an
      `import`.
  17. Jul 10, 2024
  18. Jul 09, 2024
  19. Jul 04, 2024
  20. Jun 28, 2024
    • John Swanson's avatar
      backported "Error on import into an empty appdb (#44840)" (#44850) · e8f2cccb
      John Swanson authored
      I was thinking about the potential options here.
      
      On one hand, we could initialize the app db ourselves. This is a little
      problematic, because:
      
      - our `init!` function is in `metabase.core` and calling it yields a
      painful cyclical dependency. It's also pretty tied to outputting things
      to the user that they might not expect during an import, e.g. "Looks
      like this is a new installation ... preparing setup wizard", and starts
      up jobs, etc.
      
      - if we choose to *only* initialize the database ourselves (only the
      bits that we actually *need* initialized), I'm a little nervous about
      maybe missing something. Right now we need to create the internal user
      and create users from the config file before running the import. If we
      added a third thing, would we remember to update this?
      
      - we could refactor to put all of the above in one spot, but this is a
      P1 and it feels important to close this out as quickly as possible. We
      also don't claim to support initializing the app DB from an import in
      the first place.
      
      So: just throw an exception if the app db hasn't been set up yet. Our
      heuristic here is whether a single non-internal user has been created.
      So if you want to use your config, you can run:
      
      ```
      MB_CONFIG_FILE_PATH=dev/config.yml java -jar metabase.jar
      java -jar metabase.jar import /my/exported/dump
      ```
      
      If you try to run `java -jar metabase.jar import ...` on a fresh
      DB, it'll now fail with the error message:
      
      ```
      You cannot `import` into an empty database. Please set up Metabase
      normally, then retry.
      ```
  21. Jun 25, 2024
  22. Jun 21, 2024
  23. Jun 20, 2024
    • Ryan Laurie's avatar
      :cherries: backport: Automatically add milestones to prs and issues (#44357) (#44419) · 9597008b
      Ryan Laurie authored
      * ci: Automatically add milestones to prs and issues (#44357)
      
      * automatically add milestones to prs and issues
      
      * test code
      
      * test code
      
      * test commit (#3138)
      
      * test commit (#43320)
      
      * test commit (#44357)
      
      * remove test code
      
      * add newlines
      
      * prefer older version milestones
      # Conflicts:
      #	.github/workflows/check-milestone.yml
      #	release/src/index.ts
      #	release/src/linked-issues.ts
      #	release/src/linked-issues.unit.spec.ts
      
      * type fix
      
      * backport another function
  24. Jun 15, 2024
  25. Jun 14, 2024
  26. Jun 13, 2024
  27. Jun 11, 2024
  28. Jun 07, 2024
Loading