@anonymous-piwik-user opened this issue on January 15th 2014

If in Settings --> General settings the option BrowserTriggerArchiving is disabled, you can't use the feature of custom date range. The data shown in reports like "Referrers" is incorrect.

There are use-cases for having the archiving triggered by browser disabled for the "big" archiving tasks e.g. daily, weekly, monthly, etc. on the one hand and still the need for custom date range usage on the other hand.

Data processing for the standard timerange reports is done by cron job. Of course you can't trigger the processing of data for custom date ranges by cron job.

If the processing triggered by browser in "General settings" is disabled an extra option to enable it for custom date range usage should appear.

At least this behavior should be documented in http://piwik.org/docs/setup-auto-archiving/ and noticed in the Piwik Backend in "General settings". And because for now custom date range is not working if BrowserTriggerArchiving is disabled it can be disabled as well.

Identical bug like #4069

Maybe change the functionisRequestAuthorizedToArchive in core/ArchiveProcessor/Rules.php

    protected static function isRequestAuthorizedToArchive()
    {
        return !self::$archivingDisabledByTests &&
        (Rules::isBrowserTriggerEnabled()
            || Common::isPhpCliMode()
            || (Piwik::isUserIsSuperUser()
                && SettingsServer::isArchivePhpTriggered()));
    }
@mattab commented on January 21st 2014

Thanks for the report.

When you say "incorrect reports" can you explain? Does the data displayed is incomplete and display "wrong" values ? does it display zeros ?

@mattab commented on January 22nd 2014

It was also reported in : http://forum.piwik.org/read.php?8,110249

Custom date range:

01-01-2014 au 05-01-2014 = 445 unique downloads 01-01-2014 au 12-01-2014 = 445 01-01-2014 au 19-01-2014 = 445 09-01-2014 au 19-01-2014 = 516

BUT we have for weeks:

06-01-2014 au 12-01-2014 = 1166 13-01-2014 au 19-01-2014 = 1311

@mattab commented on January 22nd 2014

Possibly also this bug in http://forum.piwik.org/read.php?2,110257

@tsteur commented on January 24th 2014

So what is a proper fix here? Adding another setting to allow triggering archiving from browser if period=range?

I tried to reproduce it and although trigger archiving from browser is disabled it did trigger the archiving but not 100% sure whether archived values are correct.

@mattab commented on January 27th 2014

Bug is that it seems in some cases, custom date ranges will not return valid data, when browser archiving is disabled.

The correct fix, is to make Custom Date ranges always work (returning correct data) when browser trigger archiving is enabled. This is supposed to work and definitely, used to work. Must be a regression from my refactoring of Archiver in 2.0

@tsteur commented on January 29th 2014

The correct fix, is to make Custom Date ranges always work (returning correct data) when browser trigger archiving is enabled.

Hey, still not clear how it should behave when archiving is disabled. Not archive at all and not display "Range" in date picker? Add another option to enable browser archiving just for range dates? Ignore the setting and archive though?

@tsteur commented on January 29th 2014

In 40eabd834f3ea90935b10c43bcf41debd29b28d3: refs #4532 this should fix custom data range values are not always working. In this case periods like week, month or year were ignored in case the data range was large enough to use one of those

@mattab commented on January 30th 2014

In bd09242078458761f9905285b5ca349172fdd149: Refs #4532 Adding integration test case for this use case

@mattab commented on January 30th 2014

In f45a66979bf47e57f78f2aae319862d3dae00d8f: Refs #4532 Adding forgotten test files

@anonymous-piwik-user commented on January 30th 2014

In 0cd0888be9fbf351a9e76cd4367cde1e715f1c10: refs #4532 easier fix with less logic

This issue was closed on February 24th 2014
Powered by GitHub Issue Mirror