In one of our hierarchy levels we have a custom ordering that isn't alphabetical. When we drill into the level on the grid, or when we open the filter popup, the level members aren't ordered according to what we returned in the /members
request (with sorted: true
), instead they get re-sorted alphabetically.
If on the other hand, we don't use the fields as a hierarchy, our custom ordering is respected.
Hello, Ezequiel,
Thank you for reaching out to us and for providing JSFiddle examples.
Indeed, the sorted: true
property is not applied for multilevel hierarchies.
Our team will provide the fix to this issue in the minor release version with the ETA 11th of January.
As an alternative approach, we kindly suggest setting the defaultHierarchySortName
option to "unsorted"
, for example:
options: {
grid: {
type: 'classic',
showGrandTotals: 'rows',
dragging: false,
},
configuratorActive: true,
configuratorButton: true,
fieldListPosition: 'right',
defaultHierarchySortName: "unsorted"
},
Here is a modified version of the JSFiddle where the ordering issue is fixed using the above approach: https://jsfiddle.net/flexmonster/gf3wpet2/
Please let us know if this works fine for you.
Looking forward to your response.
Kind regards,
Vera
Okay, that works for us! Cheers and thanks for your help
Hello, Ezequiel,
We are glad to inform you that the issue with the presorted members in the hierarchical fields was fixed.
This is available in the latest minor release of Flexmonster: https://www.flexmonster.com/release-notes/.
You are welcome to update the component. Here is our updating to the latest version tutorial for guidance.
Please let us know if the fix works fine for you.
We would be grateful for your feedback.
Kind regards,
Vera
Hello, Ezequiel,
Our team is wondering if you've found the latest fix helpful.
Please let us know if everything works fine for you.
We would be happy to hear your feedback.
Kind regards,
Vera
Hello there, it seems to work but we have unfortunately run into a different issue that prevents us from using this new version.
Even though our custom data API implementation advertises v2.8.5 support, the updated Flexmonster component is using the new FilterGroup object to query the /members
endpoint to get the hierarchy members, which leads to a error in our backend.
As it's going to take a little while for us to upgrade our backend to be v2.8.22 compatible, we'd like to file a bug regarding respecting the handshake version.
Edit: I can confirm that this bug was introduced with version 2.8.23.
Hello, Ezequiel,
Thank you for your response.
We are glad to hear that the issue with members sorting is resolved.
Regarding the issue with the new filter structure being used despite the handshake version:
Thank you for reporting this issue to us. We have managed to reproduce the same behavior on our end.
Our team will provide the fix in one of the upcoming minor versions of Flexmonster with the ETA 22nd of February.
Please let us know if this would work for you.
Kind regards,
Vera
Hello, Ezequiel,
We are happy to inform you that compatibility with older versions of the custom data source API protocol was improved.
Now the new Filter Group Object is used only if the version sent in the /handshake response is 2.8.22 or later.
This is available in the latest version of Flexmonster.
You are welcome to update the component. Here is our updating to the latest version guide for assistance.
Please let us know if the fix works fine for you.
Looking forward to your response.
Kind regards,
Vera
Hello, Ezequiel,
Our team is wondering if you've found the latest fix helpful.
Does everything work fine for you?
Please let us know if the fix helped.
Looking forward to your feedback.
Kind regards,
Vera
Hello again Flexmonster team,
We have finally implemented the new API and were able to update to the latest version of the Flexmonster component.
Unfortunately, when we're querying our cubes with the Simple Data Source API, the component still does not respect the order of the members that is specified in the /members
response.
Here's an example where I've copied over our API's actual responses and used our actual report config: https://jsfiddle.net/ezk84/cwt2j5e4/5/
We expect the Day level of the Date hierarchy to be sorted from 0 to 31, as this is the order that is specified in the members response. Also, when opening up the Date hierarchy filter popup, and we expand the 2020 > Q1 member, note that the month levels are also randomly sorted (Jan, Mar, Feb) instead of the specified Jan, Feb, Mar in the /members
response.
Notes:
/select
call seems to affect the ordering of the days.defaultHierarchySortName: "none"
option no longer helps.Hello, Ezequiel,
We are happy to hear that you've implemented the new API.
Regarding the sort issue in multi-level hierarchy members, thank you for explaining the case in detail and providing an example.
Our team is looking into your case, and we will share the results with the ETA 7th of March.
In the meantime, please feel free to contact us if any questions arise.
Kind regards,
Vera
Great, thank you.
Hello, Ezequiel,
We are happy to inform you that our team fixed the issue with hierarchy levels not being ordered according to the result of /members
request.
This is available in the 2.9.20 (latest) version of Flexmonster.
You are welcome to update the component.
Also, as a result, the defaultHierarchySortName: 'unsorted'
option is not required. Please remove the defaultHierarchySortName: 'unsorted'
option for the ordering to work correctly. Here is a JSFiddle for illustration: https://jsfiddle.net/flexmonster/w5g86o4p/.
Please let us know if everything works well for you.
Kind regards,
Vera
Thank you Vera.
I can confirm that the fix works for us. Nicely done Flexmonster Team.
Regards,
Ezequiel