Add additional_properties to UsageData API
What does this MR do and why?
Related to #434504 (closed)
With !142839 (merged), we made it possible to handle additional_properties
attribute on the backend.
Now, we want to make it possible to pass it from the frontend using our UsageData API.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Before | After |
---|---|
How to set up and validate locally
- Enable snowplow micro
- Choose an internal event and read its RedisHLL counter, for example:
Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'user_viewed_dashboard_list', start_date: Date.yesterday, property_name: :user, end_date: Date.tomorrow + 7.days)
- Create a personal access token
- Trigger the affected endpoint while sending
additional_properties
, eg.curl 'http://127.0.0.1:3000/api/v4/usage_data/track_event?private_token=PRIVATE_ACCESS_TOKEN' -H 'Content-Type: application/json' --data-raw '{"event":"user_viewed_dashboard_list","namespace_id":1,"send_snowplow_event":true,"additional_properties":{"label":"label123"}}'
, replacingPRIVATE_ACCESS_TOKEN
with the created token - Check the RedisHLL counter again [eg.
Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names: 'user_viewed_dashboard_list', start_date: Date.yesterday, property_name: :user, end_date: Date.tomorrow + 7.days)
]. This should return a value increased by1
compared to the last time.
Edited by Michał Wielich