Avoiding member calls on filterable fields with large amounts of unique data

Solomiia,

I work with Bill and took a look at your recommendation. There are a couple issues with this solution that would prevent us from using it.
First, this will only work when the field is a Report Filter. Once it is moved into a row(or column), the client will not expand any rows for the given field. Previously, in this thread it looks like there was a solution for this by setting `"filters": false` in the mapping config for the field. This fixes the problem when the field is a row, Unfortunately when we do this, the field cannot be used as a report filter. This is the biggest blocker for us since we need to support adding this field as a row at times.

Second, It is somewhat confusing when I open the report filter that it shows me the selection filter with "0 of 0 selected". The user has to have the knowledge to click into the labels to be able to apply a filter. They are still able to use the search bar but it doesn't do anything.

Third, when setting members to [], there appears to be a bug that once I set a filter via the "label" filter I am unable to ever remove the filter. If I clear the label filter, I am unable to click "apply" to close the filter modal with no filters applied.

Is there a solution that would allow us to use the field as either a row or a report filter without needing to make a members request that returns every single possible value for the field?  Given its possible to not select all members when using `"filters": false`.  It seems like it should be possible to add the ability to add a "labels" only filter for a field without making a members call for all possible values.  An example of what this might look like is here(I edit this video to what it might look like, it doesn't work like this today).

Thanks,

Brian

Hi Solomiia,

Thank you for the response. While the custom filter example is interesting, it really doesn't buy us anything because we are currently in a catch-22. If we allow the column with massive amounts of unique data to be filterable, the members API call the library makes under the covers kills our performance. If we make the column as not filterable, then the gear icon disappears and we can even leverage the event override. 

Is there a way to tell the library to show the gear icon on a non-filterable column, even if it doesn't trigger the default event? That would allow us to then implement our own custom event handler to make a server side call outside of flexmonster without us having to do crazy hacking on the javascript to try to determine what cells should have a filter icon but dont. 

Ultimately preventing the call to members for members we already have in the selected result object would be preferrable, but we could at least work around this for now if we can renable the gear icon for filtering without it making the call to members. 

Thanks,
Bill

We are going to be busy for the next week on some important projects, but once we get a chance to breath we will implement this change and let you know how it works!

Vera,

I took a look at this and it works as I would expect when I set `filters.members` to false in report configuration mapping json that is load, but it is not working as expected when returning the `filters.members` = false via the API as part of the fields response here.  When returned as part of the fields response it is still sending the members request, although it is correctly not displaying the list of values in the filter but that doesn't help with the performance issue.  Is there a way to allow us to return this value as part of the fields API response and have it behave the same as if it were configured as part of the report json?  We were trying to make this dynamic per field and having this required as part of the hardcoded configuration mapping makes that a lot harder to handle.

A sample response we are sending back as part of the fields request is:

```

{
"fields": [
  {
  "uniqueName": "field_with_lots_of_values",
  "type": "string",
  "caption": null,
  "folder": null,
  "aggregations": null,
  "filters": {
     "members": false,
     "query": null,
     "valueQuery": null
    }
  }

}

```

thank you! To be clear it appears the "members" property is in the FilterConfigObject for the custom data source API but it doesn't seem to prevent the members call like it does when adding members = false in the FieldMappingObject does.

Solomiia,

I took a look at this and it isn't working as I would expect.  When I set filters.members: false in the API response and then I expand the field in the pivot, it acts as if there are no values for that field and displays nothing.  For example here I am returning false and when I expand "Accounting Date" nothing shows.  Here I am not returning false and you can see when I expand "Accounting Date" there is a value displayed as I would expect.

When I set filters.members: false in the report mapping json it works as expected and is only not displaying the values when the fields response returns filters.members: false for the field. I attached an example of what our fields response looks like, please let me know if this is an issue with my response or something internal to the flexmonster code.

Thanks,

Brian

Solomiia, we have upgraded our support plan, so if it is easier for us to video conference with an engineering directly to show them the problem real-time in our production environment, we would be happy to do that.