New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support pivot w/ CustomDimensions #13429
Conversation
FYI because I saw custom dimension changes in another PR... changing the ID of a custom dimension may break all existing custom reports that use such a dimension or a metric https://github.com/matomo-org/plugin-CustomDimensions/compare/pivot-by |
… Report instance in PivotByDimension filter.
Ready for review. |
core/Plugin/ReportsProvider.php
Outdated
$matchParamCount = -1; | ||
|
||
foreach ($reports as $report) { | ||
$isMatchedWithThisReport = self::isReportParamsMatchingCurrentParams($report, $requestParams); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I can see this may cause problems with various plugins that are based on entities and don't create a report instance for each entity, such as funnels. By default, eg GetFunnelFlow
doesn't set parameters, but $report->parameters
may be set when configureReportMetadata
is called and I can imagine depending on the flow how methods are called that the logic might break some things.
Same is happening in GetDaysToConversion
but they set $this->parameters= array()
back in the init
method which some other report classes don't do just yet. So there might be an easy fix for this by updating all our plugins...
Is this change needed for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was needed at one point w/ some other changes, but looks like it's not needed currently. Will remove it.
core/API/DataTablePostProcessor.php
Outdated
$pivotByColumn = Common::getRequestVar('pivotByColumn', false, 'string', $this->request); | ||
$pivotByColumnLimit = Common::getRequestVar('pivotByColumnLimit', false, 'int', $this->request); | ||
|
||
$dataTable->filter('PivotByDimension', array($this->report, $pivotBy, $pivotByColumn, $pivotByColumnLimit, | ||
PivotByDimension::isSegmentFetchingEnabledInConfig())); | ||
$dataTable->filter('ColumnCallbackDeleteMetadata', array('segmentValue')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is already executed by convertSegmentValueToSegment ()
core/API/DataTablePostProcessor.php
Outdated
$pivotByColumn = Common::getRequestVar('pivotByColumn', false, 'string', $this->request); | ||
$pivotByColumnLimit = Common::getRequestVar('pivotByColumnLimit', false, 'int', $this->request); | ||
|
||
$dataTable->filter('PivotByDimension', array($this->report, $pivotBy, $pivotByColumn, $pivotByColumnLimit, | ||
PivotByDimension::isSegmentFetchingEnabledInConfig())); | ||
$dataTable->filter('ColumnCallbackDeleteMetadata', array('segmentValue')); | ||
$dataTable->filter('ColumnCallbackDeleteMetadata', array('segment')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a point in calling convertSegmentValueToSegment()
when we remove the segment afterwards?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the segment is used by PivotByDimension (useful for supporting UserCountry.City for example, whose segment involves country & region),.
@@ -267,8 +269,12 @@ private function getIntersectedTable(DataTable $table, Row $row) | |||
} | |||
|
|||
if ($this->isFetchingBySegmentEnabled) { | |||
$segmentValue = $row->getColumn('label'); | |||
return $this->fetchIntersectedWithThisBySegment($table, $segmentValue); | |||
$segment = $row->getMetadata('segment'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this fix a different bug? FYI: The segment metadata might not always be set for all reports etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see in the description mentions something around fixing segments. Not sure what the problem is and if this fixes it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, saw it while I was working. There was already a skipped test for it. This is why we call the filter above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see... do we still need the fallback for $row->getColumn('label')
as many reports won't set a segment metadata? or a dimension with a segment etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I think there were some places were the segment string was not 100% correct because it wasn't possible to do it any better but I don't remember it where...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't quite remember, but I think the label fallback is still there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I misread your question, but the label fallback is still there (it's in a ?:
expression), in case the segmentValue isn't there. I'll clear up the code since that wasn't obvious.
$segment = $row->getMetadata('segment'); | ||
if (empty($segment)) { | ||
$segmentValue = $row->getMetadata('segmentValue') ?: $row->getColumn('label'); | ||
$segment = $this->thisReportDimensionSegment->getSegment() . "==" . urlencode($segmentValue); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we be certain a segment is returned here? $this->thisReportDimensionSegment->getSegment()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn't be a valid Segment instance if it wasn't (I think), but it makes sense to avoid a fatal.
Looks pretty much fine, mostly concerned with |
Updated. |
Just tested it again and #13317 is fixed for me. 👍 (tested it with https://github.com/matomo-org/plugin-CustomDimensions/pull/100/files) |
* Supporting CustomDimensions in pivotBy. * Use segment metadata in pivotby to support more dimensions. * try to fix some tests * Update test. * In ReportsProvider::factory() match reports by parameters too + use a Report instance in PivotByDimension filter. * Fixing tests. * Fix a couple issues * Revert ReportsProvider changes. * Add git lfs pull to .travis.yml * Apply PR fixes. * Revert .travis.yml. * Update CustomDimensions submodule. * Revert tests/travis change.
* Supporting CustomDimensions in pivotBy. * Use segment metadata in pivotby to support more dimensions. * try to fix some tests * Update test. * In ReportsProvider::factory() match reports by parameters too + use a Report instance in PivotByDimension filter. * Fixing tests. * Fix a couple issues * Revert ReportsProvider changes. * Add git lfs pull to .travis.yml * Apply PR fixes. * Revert .travis.yml. * Update CustomDimensions submodule. * Revert tests/travis change.
More than a few changes to get it to work:
Fixes #13317