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
When a custom segment is used in an API request and browser_archiving_disabled_enforce=1, throw an exception explaining to create the segment first #12255
Comments
The Shouldn't |
Yes, that's by design. A super user should be able to temporarily enable browser trigger archiving (eg. via UI) to temporarily force triggering some segments even if disabled in the config.
|
Side note: maybe it would be good to disable/grey-out the |
@mattab started implementing this and I think it shouldn't be done in core. There are many API methods that don't care about segments or will work w/ segments (and potentially many in future plugins) and there's no way for core to know about all of them. So by throwing an exception we could be creating errors for API methods that should work (eg, listing report metadata). My current solution has a blacklist, but even then plugins will have to remember to add methods to the whitelist, and that shouldn't be their responsibility (in other words, plugin developers shouldn't have to remember to take This behavior can be accomplished pretty easily w/ an event on |
@mattab left a comment for you ^, can you take a look when you have a chance? |
👍
blacklist/whitelist solutions (or an event) are definitely not suitable. the only solution is to detect for sure that a segment is being used as part of an archive request (ie. that actively tries to trigger an archive) and only then throw an error. In your example of listing report metadata, the archiver code shouldn't be triggered (the codepath of creating a new archive wouldn't be created), and therefore the error would not be thrown. I realise the issue description wrongly says "When the segment does not exist in the DB (ie. a "custom" segment), then the data will never be displayed in standard reports" when I really meant something like "When an archive is attempted to be created/read, and the segment does not exist in the DB, then...." So hopefully there is a way that we can only throw this error in APIs, when the archiving was tried but failed due to the browser_archiving_disabled_enforce=1 setting? |
Managed to get something working, thanks for the bit about archiving 👍 Added to #12823 |
Re disabling, there appears to be a config option for that already, |
Use case
As an API user, when I call the API to fetch a segmented report, and use a custom segment (ie. i didn't create it via segment editor but manually constructed the segment parameter in my API request), if the config.ini.php has
browser_archiving_disabled_enforce=1
, my response will always show "no data", and I don't know why. I need to see clearly in the API response somehow that I need to manually create the segment in the segment editor first, before being able to fetch the data via the API for this segment.Reproduce
browser_archiving_disabled_enforce=1
in config.ini.phpResult: always show 0 / no data.
Steps
It's important to fix this issue because it is setup this way for some Piwik service customers.
When
browser_archiving_disabled_enforce=1
and the API is used with a&segment=
parametersegmented reports are processed in real time (default)
, then the segment data will never be displayed in standard reports (it will however work in Real time reports). In case the data would never be displayed, we would need to throw an exception:Feedback welcome, the goal is to make it crystal clear to users why there is no data and what to do to get data.
The text was updated successfully, but these errors were encountered: