Attached test case that shows the issue.

Steps to reproduce:

• Load welcomeICEfaces.jsf
• Add in '10' to the filter input field for the Accel column.
• Sorting on the Weight or Chassis columns shows unexpected results and causes other Accel values other than '10' to be shown.

Not sure if this is a real bug or just confusion due to the grouping behaviour that if one group row is shown after a filter, then all rows in that group should be shown.

Perhaps we should make that aspect configurable, as it's not very intuitive and may not match everyone's requirements.

The aspect you mention Ken is already configurable and disabled by default. I have confirmed this issue and it is due to an actual bug due to the introduction of filtering. This may be a regression.

This may not be a regression; though it only appears in particular cases. The complex case displayed in the row grouping example in showcase with the same features (sorting + grouping + filtering) appears to work as expected.

My guess is, that like several other filtering and other issues, the state saving is broken at some point due to row index issues, and the complexity of the showcase case causes data model regeneration more often, preventing the issue.

I'll try to pinpoint which features are making a difference in an attempt to find the point at which we need to force regeneration.

Component binding was the feature working around this issue. I guess that because of the longer component instance lifespan a correct model is just cached longer, or maybe created sooner.

Revision #29484
Committed by nils.lundquist
2 minutes ago ICE-8226 - Added model regeneration to fix index-bugged state loading during grouping check.

Issue is still seen with latest (03/07/2012) trunk jars.

After filtering takes place and then a sort is performed row data seems to be replaces. Here are the steps to reproduce and the seen and expected outcomes:

• Load welcomeICEfaces.jsf
• Filter on Accel column filter with a value of '10'
• It shows two rows for the Van grouping. The weight column values for these are (15383 and 11952).
• Sort ascending (^) on the Weight column swaps the second Van row for a new value that also includes a '15' in the Accel Column.
• I would expect that sorting on the Weight column would sort for the two rows that are for the Van column grouping.

I will attach some screen shots showing this. Let me know if what I think is the expected behaviour isn't.

Revision #29834
Committed by nils.lundquist
A minute ago
ICE-8226 - Prevent accidental disposal of DataModel during lastColumnDifferent grouping check when setting previous row index for the first row.

Previous regeneration was only required because the data model was being disposed of by the lastColumnDifferent check setting the row index to -1. I'd thought the model entered the check with this state, so my previous commit attempted to fix this by regenerating (in lastColumnDifferent) the model, which corrects subsequent rows; however because this code is called for each cell, the next cell of the first row again incidentally disposes of the data model, resulting in incorrect (unfiltered) cell state.

Revision #29840
Committed by nils.lundquist
A minute ago
ICE-8226 - Backporting fix for filtering + grouping state issue.