In some cases it might be useful to join tables to visitor data using other columns than
There is already a method
LogTable::getWaysToJoinToOtherLogTables, which makes it possible to define ways to join the table other than using
But currently that method is only used in PrivacyManager in order to remove related data.
This change should also make it possible to use tables joined by
getWaysToJoinToOtherLogTables as dimensions and in segmentation.
Those PRs are always tricky :) We would need to run all system tests of all premium features and for custom reports on top the integration tests to make sure everything will still work fine. (I suppose it will as they mainly define arrays in the archiving anyway so this logic should be ignored). Can you run them or should I?
@tsteur Updated the branch. Regarding running the tests. Would be nice if you could run them as well. Would need to set up a new vm to do that properly, as my current setup uses php 5.5. Some of the plugins have failing system tests due to sorting issues...
@tsteur I've now implemented the automatic join up the hierarchy if it's joinable with
log_action. To prove that works as expected I've added a new plugin
ExampleLogTables which includes two custom log tables. One that joins to
log_visit using the
user_id column, and another log table that joins the other custom table using another custom column. Also there is a custom dimension/segment for both log tables.
The plugin includes various system tests to check that all APIs/archiving still work when using a segment of one of the custom log tables.