Hi Deepak,

For that have your original list data in a local list variable called FullData and 

create another local list variable to store FilteredData.

Also create one more local list variable to store the selected Ids.

The approach is,

1. Fetch the full source data and assign it to filtered data variable on after fetch of data action.

2.  Make sure you have assigned the filtered data variable as the source to the table.

3. When the user is searching the records, filter the FullData variable and replace the data in filteredData variable.

4. Now, when select all is selected, loop the filtered list and append the ids from filtered list to selected ids make sure the current ids are not already exists in selectedIds.

5. Apply check box checked condition with the help of listIndex in the UI property of the checkbox.

Hope this helps. 

For the search part, the IsSelected attribute is handled on the client side. So, when you type something in the search, the aggregate is refreshed, and the attribute is reset as well.

To persist this behavior, the only reliable way is to shift to a server-side approach. This means that the IsSelected attribute should become a normal attribute in the actual entity instead of a calculated one. Each time a record is selected, it should be updated to true in the database.

Also, keep in mind that you will need to handle this properly in the screen lifecycle. Another important point is that it is best to use a mapping process from the aggregate to a local list variable in OnAfterFetch.

So the scenario works like this:

You are on the screen, and when you select a record, IsSelected is updated in the database. If you choose Select All, you loop through the list and update each record in the database based on the current IsSelected values.

If all records are true, then you update all of them to false. If some are true and some are false, then you update all of them to true. If all are false, then you update all of them to true.

When you navigate to another screen, you will need to reset everything by updating IsSelected back to false in OnDestroy, so when you return, you do not see any pre-selected records.

If you perform a bulk action (like processing or inserting records), you first filter and use only the records where IsSelected = true, process them, and then reset IsSelected back to false again. This ensures that after a refresh, all records appear unselected.

The search is also handled properly in this case since everything is managed on the server side.

This is essentially the only way to reliably persist this kind of selection behavior.

@Sherif El-Habibi ,

• That would not work in an application with more than 1 user
• I get that it is just an example, but iterating client side to do a server call is bad example, and there are also juniors using this forum
• Partially because of the above, it is very slow for select all
• It is weak, the OnDestroy is not guaranteed to run (e.g. closing the browser)
• select all onchange is not working correctly, just one example
  • select all
  • unselect one from the list (the select all checkbox stays true ??)
  • then uncheck the select all => all become selected (not correct)
  • then check the select all => all become unselected (not correct)

What you are trying to do comes with a world of pain, not only to implement, but to also get the UX right.  

For example, what if a, b and c are selected, and then user sets a filter where b doesn't match it, then you want to still have 3 total selected, right?  The fact that b temporarily doesn't match the filter should not unselect it.  At least, that's what i get from your questions.

But what are you going to show to the user, only a and c and all the other (unselected) that match your filter ?  How can the user still understand at that point that he didn't loose the selection on b ?

If the user selected b with a specific filter, and some filters later, he wants to unselect b, it has to still be available for him to do that without having to go back (if he even remembers) to the filter that b matches.

And at some point, you want to do something with the selected items, right ?  If at that point, there is a filter active, how will the user understand on what total list of selected items he is acting if only part of the selected are shown in the filtered result.

One possible way is to have always in the filter Or IsSelected, meaning you always show all the selected (even if they don't match the current filter) and all the unselected that match the filter.  But even this gets weird if user will typically select a lot (definitely if it would go beyond pagination)  

Another UX thing to solve : If your user checks or unchecks the 'select all', does he mean, [all that i am seeing now] (this page) or [all that fit my current filter] (possible multiple pages) or [all the items in the database] ???  Even if you agree one of these with your business user now, how will future junior users understand the implication of (un)select all ?

You could try to avoid this ambiguity by having 2 lists, the selectable and the selected, so you can apply the filtering on the selectable without the user losing track of the selected.

--

I occasionally come across this type of requirement (select in row + select all at top) and my first attempt is always to 

• avoid any filtering
• if possible even avoid more than 1 fetch (i.e. no server pagination)  

That can only work if the list is shortish.

If that's not possible, your code becomes exponentially more convoluted, because at that point, you have to maintain (on client side) a list of selected id's (the full list, not just the ones currently shown to the user) with every (un)select action, and your fetch has to export an isSelected, based on this list of selected id's.  

If you are happy with the selected just 'disappearing' when filtering (i wouldn't !) you could get away with just doing an aggregate without taking into account the selected list, and then iterate the result to mark the selected.

If not, that's one step further into complexity, you now have to replace the aggregate by an sql widget, do a buildsafe to take into account the selected ones in your query

• an OR {Entity}.[Id] IN ... to get all selected in the result, even if they don't match the filter
•  since you have the list of selected id's available in your SQL
  • you can let it calculate the IsSelected, no more need for post processing
  • you can also allow the user to sort on it

It is, as a developer, of course a joy to be working on the most complex solution, but making it more complex than it needs to be is a big waste.  (as is making it not complex enough, but then the cost shows up later)

Dorine