Compute row percentages in PHP before metrics are formatted to avoid percentage formatting WARNINGS. #15304
Conversation
…percentage formatting WARNINGS.
diosmosis
added
not-in-changelog
|
@diosmosis where can this be reproduced the previous issue? |
|
@tsteur open any product report in the UI, eg, https://demo.matomo.org/index.php?module=CoreHome&action=index&idSite=62&period=day&date=yesterday#?idSite=62&period=day&date=yesterday&segment=&category=Goals_Ecommerce&subcategory=Goals_Products , then look in the settings page for the warning notifications. |
| @@ -1,20 +1,19 @@ | |||
| {% if column in properties.report_ratio_columns and (column in totals|keys or forceZero|default) -%} | |||
| {% set reportTotal = totals[column]|default(0) %} | |||
| {% if siteTotalRow|default is not empty %} | |||
|
|
|||
| {% if siteTotalRow is defined and siteTotalRow is not empty %} | |||
There was a problem hiding this comment.
@diosmosis do you understand why we calculate the percentage differently
- The percentage value we actually show is based on reportTotal
- The percentage value in tooltip is based on siteTotal
I wonder if we can't always use the same logic? Eg always use reportTotal? Then we wouldn't even need to do the API call in the HTML table maybe. I suppose the reportTotal may be formatted as well though. Actually I think I get it... the siteTotal is without segment while reportTotal may have a segment...
Looks good to merge @diosmosis
There was a problem hiding this comment.
Actually I think I get it... the siteTotal is without segment while reportTotal may have a segment...
Interesting, I had no idea why this was there :)
There was a problem hiding this comment.
Actually, I just tested it and it does actually not seem to be the case. I reckon the siteSummary might not be needed at all and we can just use the same percentage as we show in the table based on reportTotal?
There was a problem hiding this comment.
Looks like this is the commit that differentiated between totals & siteSummary: bb0e02d
Maybe siteSummary was supposed to get the data w/o segment, but because we weren't using Request::processRequest(..., $default = []) or something similar, it wasn't working as expected? I wonder if this is actually a bug and we can fix it by making siteSummary work the way you thought it worked.
There was a problem hiding this comment.
Sounds great to add the default 👍
|
LGTM @diosmosis seems like some UI tests maybe need to be updated as for some reason the hidden ratio maybe is taking more space? Maybe those tests are failing though also in 3.x... I'll restart the PR travis jobs |
|
@tsteur looks like the precision changed: https://builds-artifacts.matomo.org/matomo-org/matomo/ratio-percent-unformatted/37553/ViewDataTableTest_14_visits_percent.png odd... will look into it |
|
Funny indeed since I thought this percentage was only used for the title but not for the shown value |
…percentage formatting WARNINGS. (matomo-org#15304) * Compute row percentages in PHP before metrics are formatted to avoid percentage formatting WARNINGS. * do not fail if site summary is not available * Make sure siteSummary requests total data without segment. * Make sure proper precision is used. * try to fix tests * update expected screenshots
…percentage formatting WARNINGS. (matomo-org#15304) * Compute row percentages in PHP before metrics are formatted to avoid percentage formatting WARNINGS. * do not fail if site summary is not available * Make sure siteSummary requests total data without segment. * Make sure proper precision is used. * try to fix tests * update expected screenshots
Fixes #14540