Stores a heap of information every time a user "visits" the app.
Events
Allows to store events (usually == user actions) and connect them to a visit.
Record History
Yournaling already had a self-baked way to store changes of records. This was done over the RecordHistory model. This change renames the model to RecordEvent and makes in compatible to the Ahoy::Event interface.
Now there are two ways to record an event:
RecordEventService.call(...) - the previous way, usually called inside a transaction
ahoy.track("event name", {...}) - the gem's default, which seems to do a lot and might better be queued
Food for thought
Use ahoy.track for all kind of events - also those that do not change a record (e.g. page visits, pagination, searching, filtering of lists...).
Keep RecordHistory as it was and keep calling it in a transaction to always have a full history of changes to a record (though we do not store all changed attributes (yet?).) Being able to display this to the team admins has a value! Enqueueahoy.track (with record_history:) in the transaction in which we write the RecordHistory.
TODO
[ ] check GDPR-conform-configuration
[ ] decide if RecordEvents should really be used for Ahoy::Events, or if we should keep the concepts separate
mediafinger
commented
4 weeks ago
Ahoy ⛵
Visits
Stores a heap of information every time a user "visits" the app.
Events
Allows to store events (usually == user actions) and connect them to a visit.
Record History
Yournaling already had a self-baked way to store changes of records. This was done over the
RecordHistorymodel. This change renames the model toRecordEventand makes in compatible to theAhoy::Eventinterface.Now there are two ways to record an event:
RecordEventService.call(...)- the previous way, usually called inside a transactionahoy.track("event name", {...})- the gem's default, which seems to do a lot and might better be queuedFood for thought
Use
ahoy.trackfor all kind of events - also those that do not change a record (e.g. page visits, pagination, searching, filtering of lists...).Keep RecordHistory as it was and keep calling it in a transaction to always have a full history of changes to a record (though we do not store all changed attributes (yet?).) Being able to display this to the team admins has a value!
Enqueue
ahoy.track(with record_history:) in the transaction in which we write the RecordHistory.TODO