This is the expected behavior, in OPS as well.

Oh, ok.

To me it feels weird that if i select the rows, and sort, i loose my selection.

But we should leave it for now. If IRSA/LSST want to change it, we''ll change this to "new feature" or "improvement".

Xiuqin, i've changed this ticket to improvement because it was always behave the same in ops and in the past.
I feel that this could be a good improvement: the selected rows in a table should be kept after sorting. We probably put it as part of a different epic and in backlog.

What do you think?

I saw long ago that this was marked "Done" and I stopped worrying about it.  But I see that on Ops right now only the first part of the request - don't clear checkbox selections when sorting - was done.  However, the "The checked rows should be still checked ... and after apply/un-apply filters." part was apparently not done, and is really just as important, if not more.

Sorting and filtering should never change checkbox state.  Also, equally important, the "master checkbox" in the upper left should not change the checkbox state in either direction of rows that are not selected by the current filter (i.e., not visible).  (This cannot be tested now because filtering currently clears all checkboxes.)

If this is controversial, we'll need a discussion.  Shall I file a new ticket?

There are several issues we need to resolve before it can be implemented the way you've described.
Imagine a user selected all of the rows, then filter down into a few...

• download selected:  Is it reasonable to have the user download something they cannot see?
• filter on selected:  Either from chart, image, or table, should it bring back the invisible rows?
• how do you unselect the invisible rows?

Also, there's a technical issue as well.  All along, 'selected rows' is represented as indexes of the current(filtered/sorted) table.  This logic has spread out into other component's code, like chart and image.  In order for this to work, beside fetching the required columns, they need to fetch the row ID of the 'original' results set.  It's definitely something we can do.  But, more thorough regression testing is needed.

 Loi Ly pointed more issues out. The original issue seems easy, but has high impact. Gregory Dubois-Felsmann, please file a new ticket with Firefly_CCB label.