recent_views stored in user local setting (#29631)
* First pass at recent_views stored in user local setting This modifies the view log event handler to write a user's views to their local settings map (stored as json in the appdb). some notes on what causes a view :card-query - occurs when collection with pinned cards/models is opened. maybe shouldn't count as a view :card-read - happens when you view a card, like, load it in the UI and are looking at it :card-read AND :card-query - happens when you view a model, like, load it in the UI and are looking at it :dashboard-read - happens when you view a dashboard :card-create - when you save a card - this will probably cause double counts because it will save and then trigger a :card-read right away too :table-read - when viewing a table. - when selecting a db/table in dropdowns in the Question editor I think we need the view log topics to be much smaller: #{:card-read :dashboard-read :table-read} * WIP test for the recent_views user local setting. This isn't totally correct yet. I think it doesn't clean up after itself correctly. That's pending. And, I have to investigate because :table-read isn't working either. Still worth pushing this progress! * Test that works! All potential view events need :actor_id * Working test for /api/recent_views * Order of views in user-local recent-views works now If a user views something they've recently viewed, the homepage order doesn't change. Now it will, as in, the most recently viewed item will always be the first item in the vector. * One time recent_views expensive query done in the user-recent-views getter The logic of filling the recent-views setting was first written in the activity api namespace. Now it's handled where the setting is defined, which lets anyone else consuming the setting not worry about filling it if its empty. The setting can be reset with `nil` which will cause the query to run again. Otherwise, if the list of recent items is an empty vector, that is considered valid and will not re-run the query. Updating the setting per view is handled still in the view log handler, implemented in the private function `update-users-recent-views!`. * Add `most-recently-viewed-dashboard` setting The most recently viewed dashboard for that user, in the past 24 hours. This is not meant to be a permanent solution to providing this bit of info for the user, rather, it's a 'stop gap' while the audit tables are reworked. * Add test for most recent dashboard setting * Pass :context to the view log fns This lets us filter out views triggered by pinned cards. * Fix tests failing after adding :context to view metadata * See if card-query can help us filter out pinned item views * Tests should send :card-query events * Since we use :card-query, we have to filter out dashboard context too This should prevent views being recorded if someone just opens a dashboard. * ViewLog Cleanup to see if it'll let other tests pass
Showing
- src/metabase/api/activity.clj 11 additions, 74 deletionssrc/metabase/api/activity.clj
- src/metabase/events.clj 6 additions, 1 deletionsrc/metabase/events.clj
- src/metabase/events/view_log.clj 121 additions, 6 deletionssrc/metabase/events/view_log.clj
- src/metabase/query_processor/middleware/process_userland_query.clj 1 addition, 0 deletions...ase/query_processor/middleware/process_userland_query.clj
- src/metabase/server/handler.clj 1 addition, 5 deletionssrc/metabase/server/handler.clj
- test/metabase/api/activity_test.clj 57 additions, 45 deletionstest/metabase/api/activity_test.clj
- test/metabase/events/view_log_test.clj 69 additions, 1 deletiontest/metabase/events/view_log_test.clj
Please register or sign in to comment