Filter White-Listed Fields
Previously, I was able to provide a top-level object field as a white-listed filter field and all sub-level fields would be included. Now, this is NOT allowed. My app is user customizable, in which they can create new fields to this object at will. There is no way I can maintain the white-listed sub-fields when my app uses a NOSQL approach, but yet the Charts filters are not. All of my charts are now coming back with Errors and won't load because of this change. Can you please please please provide the ability to specify a top-level object field and ALL sub-fields be included?

-
AdminTom (Admin, MongoDB) commented
Thanks for following up. So you are correct that verified signature embedding never used the filter whitelist - this only applies to unauthenticated and the new authenticated embedding. While we are deprecating verified signature embedding (since authenticated is generally easier and more powerful), we won't be disabling it any time soon and we'll make sure we support the document-level whitelisting you require before we do this. So it is fine to keep using verified signature in the meantime if this has the features you need.
-
Solutegrate Support commented
Also, I believe I read that verified signature is being deprecated. So if I do get this to work using that, how long will it work? I’ve been telling my clients that they can filter charts based on they’re custom properties, but I don’t want to be “selling” this as a feature if in the near future it stops.
-
Solutegrate Support commented
Thanks Tom! Unfortunately, that’s how I found out about this error. My charts have always been setup using verified signature, which I guess that’s why it always worked with the filtering, but as of this morning I kept getting errors in my charts saying they weren’t enabled for embedding. I sent support a message about it and they had no answer. So then, I changed the embedding to unauthorized and that’s when I ran into the filtering error.
-
AdminTom (Admin, MongoDB) commented
Thanks for the suggestion. We haven't ever changed the behaviour here - it was always necessary to whitelist each exact field you want to use. However I think this is a valid feature request for people that use dynamic schemas.
In the meantime, you could work around this by using the Verified Signature embedding model which does not use whitelists.