Change the criteria for Recents in the Data Picker about metabase HOT 3 OPEN

see discussion re potentially logging "selections" independent of "views" so that we can slice these things more finely in various places

from metabase.

Summarizing our decisions regarding this idea:

API To track selection events:

• POST /api/activity/recents
  Whenever a selection occurs, the frontend will send a post body like:

{
  id: number, 
  model: 'card' | 'dataset' | 'dashboard' | 'table' | 'collection',
  context: 'selection'
}

API To read recently selected + viewed items

context is a required query parameter, and dictate what keys will be in the response.

1. GET /api/activity/recents?context=view
   returns recent view items only

{"recent_views": [Items...]}

(n.b. this is the exact same thing as /api/activity/recent_views)

2. GET /api/activity/recents?context=selection
   to get only views or recently-selected items:

{"recent_selections": [Items...]}

3. GET /api/activity/recents?context=all
   gets both, under the 2 keys:

{"recent_views": [Items...],
 "recent_selections": [Items...]}

Backend details

We should add context, a non-nullable text column to the recent_views table, that can be used to differentiate these two kinds of views. That should allow for easily expanding the recents purview.

The 4 or 5 big queries will need to be parameterized with context: either selection, view, or both of them, so we can keep the query upfront. We can still pass everything through

Garbage Collection

For deduplication, we would need to delete all but the most recent values for all rows with the same (user_id, model_type, model_id, context) therefore context will need to be considered here. Then for compaction, we delete all but the latest 20 items per user_id x model_type x model_id x context

• As it is now, we make a query for duplicate items, and delete all but the newest entry when there is a collision on (user_id, model_type, model_id, context). I think it is time to closely consider improving the recent_views schema, to be unique on those fields, and simply do upserts when there is a collision on (user_id, model_type, model_id, context). This will let us stop doing manual deduplication.

• Add POST /api/activity/recents to record selection events (.5 days)
• Create the GET /api/activity/recents?context=view endpoint (.3 days)
• Update db schema + backend to return selection events (2 days)
• Compaction on multiple contexts (1 day)
• Update the api to be able to return both (1 day)
• tests + ci (1 day)

from metabase.

Frontend Tasks:

1. Adding a request to POST /api/activity/recents to record selection events
2. Update the request for GET /api/activity/recent_items in the data picker to GET /api/activity/recents?context=selection, and use that list instead (the exact same shape is returned, so nothing else to do there).

POST /api/activity/recents

Whenever a selection occurs, the client will send a post body like:

{
  id: number,
  model: 'card' | 'dataset' | 'dashboard' | 'table' | 'collection',
  context: 'selection',
}

from metabase.