Hi Konstantin,

Indeed our data is not aggregated on the client as we have thousands of records that we need to aggregate on several levels, so we do it on the server and return a GroupResult, as stated in point 3 of the docs.

We don't make use of setGroupIds to identify the group rows for the purpose of controlling collapsedIds, because we can set the unique IDs of those groups on the server while processing the whole data.

Given that GroupResult interface doesn't impose any restrictions on what the grouping ID should be called and Kendo doesn't rely on that (it's for our own use in onExpandChange handlers) we just used the same "Id" property to identify our group rows (instead of "groupId"), the same way we identify our data items. Which brings us to this issue.

We just updated our server code to use a different ID property for the group rows and it solved the problem. So to rephrase - everything works fine if we follow the examples and the built-in data utils from Kendo, but if we build our data on the server, there is a restriction that is not documented - we can't use the same "ID" property to identify the groups as the one used for the data items. Even if we rely on the Kendo data tools' "setGroupIds" to populate these unique IDs on the client after the data is returned from the server, there would be an undocumented limitation that our dataItemKey for the data items cannot be called "groupId".

Given that DataGrid grouping functionality is usually used in enterprise applications with unique custom requirements, I think it is possible that other people might hit the same issue. I believe a proper fix for that occasion would be no more than a line of code from your side and is better than bloating the documentation with an obscure restriction.

Also, the reason it doesn't throw warnings in Konstantin's example is because the groups don't have the ProductID property, so Kendo falls back to using the absolute index for the keys of these rows as if dataItemKey was not provided. In our application groups and items all have ID field, which we use for dataItemKey and the issue is still there.

Hello Konstantin.

I am sorry I did not clarify this earlier.

I am aware that groupId is not available on the leaf nodes, just the parent group items. However, this has no relation to the issue, as even if you supply a property that is available on both groups and items (as we do in our real application, I just don't want to modify the data in the example so much) - the result is the same. The problem comes from the following lines of code in Kendo's Grid.tsx source:

 

The dataItemKey constant in the above snippet respects only the id of the group row (we have 1 group record with unique ID in the data, but 2 rows generated for it - one group header row and one group footer row) - so we end up with them having the same key.

I am attaching a screenshot to show which two rows I am talking about - they both have their key set to the same value: "0UnitsInStock_Alice MuttonProductName". If we do not provide the dataItemKey prop then as seen from the snippet kendo uses the absoluteIndex of the row, which is different for group header and footer rows and there is no issue.