report filters ignoring MDX filtering

from the looks of it we need to add additional filtering by "Branch" for each dimension we use then the filter options in the report actually show only the data we need, we kinda hoped that we can filter the "Branch" dimension only and then all the rest of the dimensions having a link to the "Branch" dimension will be filtered automatically.
Anyway, works fain as is, just few additional lines to define filters.

Hello,
Is there any progress on this? I'm using the Angular implementation (ng-flexmonster) of the Flexmonster tool and 'subquery' is apparently not a part of 'DataSource' (yet?). I would love to know how Nikolay got around this issue, since I tried setting the filter property of columns, rows, AND the reportFilters to all have the same members and I still get more data in the filter dialog then I want/need.

Hi Dmytro,
Unfortunately, the "subquery" option did not work for me. The table filters still showed values that should not be included in the returning data set. Is there another workaround that I can use to make sure that only the filtered data values show up in the table filters? It's a security issue at my company.
Thanks,
Jon

Hi Dmytro,
I think my question can be better exemplified if I modify the JsFiddle you made earlier above (https://jsfiddle.net/dftcv973/). In this example, I simply changed out "Account Type" for the column you had initially. Here, on the grid, we can see that there are only two results that come through for the given geography "United States" that was part of the subquery. But if we click on the filter button next to "Account Type", it lists what I gather is ALL of the account types in the database/OLAP cube structure. I guess what I'm asking is can the subquery affect all other dimension filters as well? So that if we filtered by "United States", if I clicked on the filter button for "Account Type", it would only show "Expenditures" and "Revenue" as possible options? Or is that somehow an OLAP cube configuration thing?
Thanks so much for your time,
Jon

Hi Tanya,
 
That's the answer we eventually came to also. As it stands right now, I'm interrupting the "DiscoverMembers" response, removing the members I don't want to show up in the filters dialog, and updating the "all" and "count" properties before continuing to send the response back to the UI. Does this sound correct?
 
Thank your for your time yet again,
Jon

Hi all,
 
Just a bit of a follow-up. We found out that if you straight-up remove members as they go through the DiscoverMembers response stage, the mapping with the Execute stage doesn't update. Apparently the ordinals and level ordinals get thrown off and the returned data is slightly off in it's coordinates. I just wanted to ask if there is any discussion for offering an option to "filter the filters", as it were, in the near future. My company deals with reports that are multi-tier at times (multiple columns and rows), which complicates matters when we find ourselves in a situation where we want to only show user-role approved values in the table filters to the client. DiscoverMembers is a good place to start, but then updating the ordinals and trying to map the changes over to an exponentially complicated "columnlist" and "rowlist" in Execute seems nigh impossible. Thanks for your help in this, but we had to eventually just turn table filters off because of the issue. Please let me know if any changes to this feature is in the works.
 
Thanks again!
Jon