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 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.