asked on June 10, 2022
Currently we can set a lot of the mapping object options through responses in the /fields request, for example describing fields that form a hierarchy, the folder where fields should go, captions, etc.
Properties are designated in the mapping object as:
mapping: {
"Field Unique Name": {
hierarchy: "Hierarchy Name",
type: "property"
}
}
In the /fields request however, the type is already used to determine the data type of the field (one of string, number or date as per the documentation).
Can there be an alternative way to assign these higher-abstraction field types while not losing the ability to assign the data type?
Right now if I have a field that is part of a hierarchy but without a parent (as a property would be), the field is automatically added to the hierarchy but it doesn't behave like a level (it literally doesn't expand) nor does it disappear as if it was a property. It would be nice if I didn't have to specify a mapping object in the front end component to fix this.
⋅ June 13, 2022
Hello!
Thank you for contacting us.
Kindly note that Custom API data source doesn't support the property datatype for now. The datatype property was created for the JSON data source and is used to pass additional information to the client. Also, it allows filtering the data column out of the Fields List.
Considering the information above, could you please provide us with more details, mainly:
1. What is your original use case?
2. What is the desired data visualization you want to achieve by using the property datatype?
It would greatly help us to give you a more case-specific suggestion.
Looking forward to hearing from you.
Regards,
Solomiia
⋅ June 21, 2022
Hello!
Hope you are doing well.
Our team is wondering if you had some time to look through our questions. Could you please provide us with mentioned details of your case?
Looking forward to your response.
Regards,
Solomiia
⋅ June 28, 2022
Hello!
Hope you are having a great week.
Just checking in to ask if you have any updates on the case. Have you managed to find the workaround?
Looking forward to hearing from you.
Regards,
Solomiia
⋅ July 11, 2022
Okay, let me try to illustrate with an example:
I am running a cube with a number of fields related to a Geography hierarchy: Geo Type > State > Geo Name. This hierarchy is established through the results of the /fields request.
Additionally, there is an extra field Geo ID that does not belong in the hierarchy but is related to this hierarchy's lowest level members. Thus to make it be part of the hierarchy semantically, in the front end we are adding a mapping object like this
mapping: {
"Geo ID": {
hierarchy: "Geography",
type: "property"
}
}
What this achieves is:
What we consider cumbersome is that up until this point we have been able to entirely define the hierarchy from the backend, but to achieve the above we are having to add these extra bits of configuration in the front end which is more costly to maintain and creates a lot of duplication.
Note that the alternatives are either to:
⋅ July 12, 2022
Hello!
Thank you for getting back to us. And special thanks for the detailed explanation of your use case. It helps us a lot to understand the matter.
We kindly suggest using the visible option of the mappingObject for the described case. It will hide the field from the Field List when set to false. The property can be configured in the mapping as follows:
mapping: {
"GeoID": {
visible: false
},
}
Here is a JSFiddle example for visualization: https://jsfiddle.net/flexmonster/omz6dvcf/.
For more details about mapping, please look through our docs:
https://www.flexmonster.com/api/mapping-object/.
Hope you will find this answer helpful.
Regards,
Solomiia
⋅ July 19, 2022
Hello!
Hope you are doing well.
Our team is wondering if you had some time to try the visible option of the mappingObject. Could you please let us know if it works for your case?
Looking forward to hearing from you.
Regards,
Solomiia
⋅ July 26, 2022
Hello!
Hope you are having a great week.
Just checking in to ask if visible option works for your case.
Looking forward to your response.
Regards,
Solomiia
⋅ August 2, 2022
Hey there,
I was on holidays so could not get back to you sooner.
The solution you propose still seems to require me to make configuration changes in the front-end of the application, this isn't much different from the previous solution with using the type: "property" mapping.
We are looking for a solution where this configuration can be set by the backend through the Custom Data Source API the way "folder", "hierarchy" or other field settings are able to be expressed by the backend.
Is the visible flag available to be set via the Custom Data Source API in the /fields request?
⋅ August 3, 2022
Hello!
Thank you for getting back to us.
If you need to hide the GeoID field from the server side, we kindly suggest pre-filtering fields before sending them to Flexmonster via the /fields request.
Please, let us know if this approach works for your case.
Regards,
Solomiia
⋅ August 3, 2022
Yeah, I guess that's the nuclear approach. We can try that.
It would be nicer if we could include it and have it turned off, while the few reports that may need the Geo ID can use their mapping to show it, but I understand that this isn't possible right now.
Thanks for your help.
Ezequiel
⋅ August 4, 2022
Hello, Ezequiel!
Thank you for your swift response.
We are glad to hear that our suggested approach works for your case.
You are welcome to ask if any other questions arise.
Regards,
Solomiia