asked on October 8, 2021
Hello,
We believe we have found a bug in regards to built-in front-end aggregations and filtering when the datasource is the custom api. We have prepared a jsFiddle and video for convenience.
/select request as a part of applying the filters, we noticed that the built-in front-end aggregation was sent as a part of the filter object. Specifically, the func property was set to the built-in front-end aggregation, e.g., percentofparentcolumntotal.
To our understanding, the custom api protocol should not be sending built-in front-end aggregations in /select requests, rather, it should only be sending those specified in the /fields response according to the documentation. Is our understanding correct? If not, how do we account for built-in front-end aggregations being sent in /select requests?
Please let us know if there is something wrong with the jsFiddle or video or if we can provide any additional information!
Kind regards,
Henry
⋅ October 11, 2021
Hello, Henry,
Thank you for reporting the issue and for preparing the detailed report.
We would like to explain that client-side aggregations are calculated without server participation. This is why the server is unable to apply value filtering for measures that currently use client-side aggregation.
We are going to disable UI controls for filtering by values for such measures. This fix will be introduced ETA Nov 2. Our team will notify you as soon as the fixed version is available to download.
Feel free to contact us if any other questions arise.
Best regards,
Illia
⋅ October 11, 2021
Hello, Illia,
Would it be possible to fix/keep the UI controls for filtering by values for such measures? We discovered this issue because someone wanted to filter the values by a built-in front end aggregation, so are seeing some use cases for filtering by built-in front end aggregations.
Kind regards,
Henry
⋅ October 12, 2021
Hello, Henry,
Thank you for your feedback.
We would like to explain that aggregations like percentofparentcolumntotal can only be calculated in the client's browser. This limitation is due to specific requirements of the client-side aggregations which cannot be fulfilled on the server.
In its turn, filtering is performed on the server-side and can only use aggregations implemented on your server.
Performing filtering on the client-side for such aggregations would require loading additional data (dataset structure, raw records, and members), which goes against the idea of the custom data source API protocol. This is also not supported by the component and protocol architectures.
Therefore, we decided to disable UI responsible for filtering values with such aggregations. It would allow avoiding unexpected errors and inconsistent behavior.
Do not hesitate to reach out if any other questions arise.
Kind regards,
Illia
⋅ October 12, 2021
Hello, Illia,
Thank you for the explanation. We can see how client-side functionality can break the protocol and understand the team's decision.
Kind regards,
Henry
⋅ October 13, 2021
Hello, Henry,
Thank you for your feedback.
We are happy we reached an understanding on this matter.
Please contact us if any other questions arise.
Best regards,
Illia