A table with multi-selection and grouping will count its group "rows" toward the selected rows count

[dguzzo]

• Goal: Have tables report the correct number of selected rows in their footer when using a table with multiple row selection and grouping turned on.

• Steps: Create a table with groupings and multiple row selection on. Try to select each individual row in the data source; note that the "group" faux rows are counted in the total, but not the selected amount:
  

  
  
  This is the actual length of the data:
  
  Then try using the "select all" checkbox and note that the group rows are counted in both the selected and total amount:
  
  

• Details: Why is this an issue? Aside from the confusing aspect of looking at every row as selected (when done individually) but no obvious accounting for the "missing" rows, it's a problem when scripting: when attempting to loop through table.selectedSourceRows, the faux group rows are included, which can lead to errors when one is expecting each row to be a legitimate iterable entry from the data source:
  
  Of course one could explicitly look for rows that might have null fields, but this feels like it shouldn't be necessary. Especially since the "group" rows don't have a checkbox and cannot be deselected unless deselecting all.

• Screenshots:
  Some of the setup configuration:
  
  

• App json export: If necessary I could probably reproduce in a one-off test app, but hopefully this is easily reproducible by anyone and isn't specific to my loaded data and other factors, etc

[Tess]

Hi @dguzzo Thanks for the detailed report! I can confirm it's easily reproducible. I'll keep you posted when I hear about a fix

[dcartlidge]

+1 to this, confusing the life out of me
5 ticked boxes. 14 "rows". 51 items.

[Darren]

Hey everybody - release version 3.299.0 shipped with a feature flag that you can toggle on in order to address this behavior.

After some additional testing, we will likely remove the flag and push the relevant changes to production for all users.