Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/metabase/metabase. Pull mirroring updated .
  1. Jun 27, 2022
  2. Jun 26, 2022
    • Nemanja Glumac's avatar
      :cherries: Manual backport of E2E/Percy related changes (#23552) · d3f0596a
      Nemanja Glumac authored
      
      * Run Percy inside E2E main workflow (#23480)
      
      * Add Percy to the main E2E workflow
      
      * Ignore unit tests
      
      * Delete Percy workflow
      
      * Do not run Percy tests on Cypress changes only
      
      * Check whether visual regression tests should run at all
      
      * Remove diff logic from Percy job on `master` (#23551)
      
      * Ignore all unit tests in E2E workflows (#23550)
      
      * [E2E] Remove filters and onboarding checks from CCI (#23517)
      
      Co-authored-by: default avatarDiogo Mendes <diogo@metabase.com>
    • dpsutton's avatar
      Join slack channels with slack-id (#23495) (#23542) · 547964aa
      dpsutton authored
      * Join slack channels with slack-id
      
      Fixes https://github.com/metabase/metabase/issues/23229
      
      We upload images to a channel and then send messages to the desired
      channel referencing those images from the channel we uploaded. But the
      slack bot must be in the channel to upload images.
      
      We handle this in `slack/upload-image!` where we watch the error message
      and join the channel if we recognize that is our issue. This special
      upload channel is set in the admin section when setting up, typed in by
      a human.
      
      Slack now requires us to use the internal id of the channel when
      joining. IE we used to use "metabase_files" but now we need to use
      something like "C87LQNL0Y23". But we do not have this information and we
      don't want humans to have to look this up.
      
      SOLUTION:
      change our cache. We currently just get a list of channels and users
      ```
      ["#general" "@dan" ...]
      ```
      
      Change this to
      ```
      {:version 2,
       :channels [{:display-name "#random",
                   :name "random",
                   :id "CT2FNGZSRPL",
                   :type "channel"}
                  {:display-name "#general",
                   :name "general",
                   :id "C87LQNL0Y23",
                   :type "channel"}
                  {:display-name "@dan",
                   :type "user",
                   :name "dan",
                   :id "UR65C4ZJVIW"}
                  ...]}
      ```
      
      Now we have slack internal ids present. When we attempt to join the
      slack channel, look for this id and attempt to use that.
      
      This has some knock-on effects. The UI still lists the channels in a
      channel picker when sending pulses. The list sent over the wire still
      mimics the previous shape (a flat list) and the choice is still the
      human readable name.
      
      In the future we should switch over to using the stable ids rather than
      solely channel names. Channel names can be renamed.
      
      I didn't go down this route because of the files channel. It is set at
      setup before we have a channel list. We could do some kind of run time
      migration but it is difficult because it would change the type of
      `slack-files-channel` from string to :json to handle the more complex
      type. Or perhaps we could make another setting to hold the json form and
      set that when we can positively identify things.
      
      In either case, these changes were not required yet to fix our slack
      issue. We just upgrade the information we have about slack channels,
      downgrade it when it hits the wire so the UI needs no changes, and use
      the extra information in the one spot where we need it.
      
      The cache is populated at startup and every four hours after that. So we
      do not need to worry about the old cache shape. If the new code is
      running, its the new cache.
      
      * Send #channel and @user forms over wire
      
      We store `{"channel": "#slack-pulses"}` in the pulse_channel.details
      column so we should keep those types of values around.
      
      We use the bare portion ("slack-pulses") rather than with the hash on it
      so we seem to be mixing usernames and channels. But these sets are
      distinct and you cannot create a channel with the same name as a
      user. Also, channel names are lowercase while channel-ids are uppercase
      so those are also non-overlapping sets.
      
      * Put slack token so slack reports as configured
      
      * Errant tap>
      
      * Alignment and docstring fixes
      
      * Remove slack-cache version information
      
      remove the `:version 2` from the cache. We are always in charge of the
      cache, and we compute it on startup so there's little risk of other data
      shapes being present.
    • github-actions[bot]'s avatar
  3. Jun 24, 2022
  4. Jun 21, 2022
  5. Jun 20, 2022
  6. Jun 17, 2022
    • Natalie's avatar
    • github-actions[bot]'s avatar
    • Diogo Mendes's avatar
      Record Cypress test runs only on master branch (#23214) · 921c667f
      Diogo Mendes authored
      * Adding logic to record currents only on dev
      
      * Remove white space
    • github-actions[bot]'s avatar
      docs - update maps (#23389) · 262d3e5d
      github-actions[bot] authored
    • github-actions[bot]'s avatar
      Handle quarters in native queries (#23368) (#23399) · 2edc2c2f
      github-actions[bot] authored
      MBQL goes through a different path. This is only for native
      queries. Also the diff is huge. Ignoring whitespace shows a very modest
      diff:
      
      ```diff
          "month"   {:unit-range month-range
                     :to-period  t/months}
      +   "quarter" {:unit-range relative-quarter-range
      +              :to-period  (comp t/months (partial * 3))}
          "year"    {:unit-range year-range
                     :to-period  t/years}})
      
      ...
      
         "past2months~"   {:end "2016-06-30", :start "2016-04-01"}
         "past13months"   {:end "2016-05-31", :start "2015-05-01"}
      +  "past2quarters"  {:end "2016-03-31", :start "2015-10-01"}
      +  "past2quarters~" {:end "2016-06-30", :start "2015-10-01"}
         "past1years"     {:end "2015-12-31", :start "2015-01-01"}
         "past1years~"    {:end "2016-12-31", :start "2015-01-01"}
      ```
      
      Helpful Testing Strategies
      --------------------------
      
      Sample DB
      =========
      
      `select id, created_at from orders where {{created_at}}`
      and set a field filter of type "Date Filter"
      
      Custom Table
      ============
      
      Create a table that has entries in the middle of each quarter.
      
      ```sql
      esting=# create table quarters (id serial primary key not null, description text, t timestamptz);
      CREATE TABLE
      testing=# insert into quarters (description, t) values ('Q1 2022', '2022-02-01'), ('Q2 2022', '2022-05-01'), ('Q3 2022', '2022-08-01'), ('Q4 2022', '2022-11-01');
      INSERT 0 4
      testing=# select * from quarters;
       id | description |           t
      ----+-------------+------------------------
        1 | Q1 2022     | 2022-02-01 00:00:00-06
        2 | Q2 2022     | 2022-05-01 00:00:00-05
        3 | Q3 2022     | 2022-08-01 00:00:00-05
        4 | Q4 2022     | 2022-11-01 00:00:00-05
      (4 rows)
      ```
      
      Before this change
      ------------------
      
      > Cannot invoke "clojure.lang.IFn.invoke(Object)" because "to_period" is null
      
      (note, if you cannot reproduce this its because you haven't gotten
      https://github.com/metabase/metabase/pull/23346
      
       in your local version
      which ensured errors always appear as errors on the frontend. java 11
      has no message for NPE so the Frontend missed it was an error and
      displayed no results as if the query had succeeded)
      
      This was the case for the following scenarios:
      - "last1quarters"
      - "last1quarters~"
      - "thisquarter"
      - "next1quarters"
      - "next1quarters~"
      
      where the ~ means to include the current quarter.
      
      After this change
      -----------------
      
      Running the queries against the custom table I made (current time is Jun
      15, Q2)
      
      - "last1quarters": "Q1 2022" "February 1, 2022, 6:00 AM"
      - "last1quarters~": "Q1 2022" "February 1, 2022, 6:00 AM" | "Q2 2022" "May 1, 2022, 5:00 AM"
      - "thisquarter": "Q2 2022" "May 1, 2022, 5:00 AM"
      - "next1quarters" "Q3 2022" "August 1, 2022, 5:00 AM"
      - "next1quarters~": "Q2 2022" "May 1, 2022, 5:00 AM" | "Q3 2022" "August 1, 2022, 5:00 AM"
      
      And of course added tests into the matrix for the date parsing.
      
      Co-authored-by: default avatardpsutton <dan@dpsutton.com>
    • github-actions[bot]'s avatar
    • Howon Lee's avatar
      JSON query in postgres now walks identifier tree if one encountered (fixes... · c27bad51
      Howon Lee authored
      JSON query in postgres now walks identifier tree if one encountered (fixes #22967) (#23278) (#23384)
      
      Pursuant to #22967.
      
      Previously the notion of the identifier in json-query in postgres assumed a singular identifier at the top-level of the Identifier record. This is not always the case in complicated binning scenarios - the identifier could also just comprise an entire tree of Identifier record maps with the actual Identifier we're looking to turn into the JSON query in some leaf somewhere.
      
      Therefore, the json-query's determination of what the identifier is now walks that identifier record tree and replaces the identifiers that have JSON field semantics with the reification of ToSql from json-query.
      
      Previous attempt at solution hacked together something at the json-query level, changing the reification, but that only worked for one level down, instead of just walking the Identifier tree and therefore getting stuff at arbitrary tree depth. And we do get nontrivial tree depth in the bucketing in #22967.
  7. Jun 15, 2022
  8. Jun 14, 2022
  9. Jun 13, 2022
Loading