Select All

The "Select All" feature is designed to enable users to select all queried records and perform actions on the entire selection. This feature is particularly useful when dealing with large datasets, allowing users to trigger actions on all queried records, not just the ones visible on the current page.

How does it work?

When a user toggles the "Select all" checkbox, Avo will first check to see if there are more records than just those displayed on that page, and if there are, it will ask if the user if they want to select all the records or not.

This is being done through serializing the query to be unserialized back in the action.

On the grid view

Since avo >= v4.3.10

The grid view gets the same bar, above the cards: a Select all checkbox for the page and, when the resource has more than one page, the Select all matching link and the Undo that drops back to the page's selection.

Actions receive the selection exactly as they do from the table, so an action that already works on the table needs no change to work on the grid.

A resource that hides its checkboxes with self.record_selector renders no bar.

Coming back to the index

Since avo >= v4.3.1

When you go back to an index page, with the browser's Back button or the Go back link on a record page, the rows you had selected are checked again and the page scrolls to where you were. Reaching the index any other way, or reloading it, starts with nothing selected. Running an action forgets the selection.

The selection is kept per browser tab and per URL, so each combination of filters, sorting and page keeps its own. A Select all matching choice isn't kept: select it again.

With session persistence on, the selection comes back however you reach the index, and is kept per page rather than per URL. Since avo >= v4.3.11

Serializing the query

The query might include various filters, sorting parameters, and other custom elements. Reconstructing this query at the time of the action request can be complex. Therefore, the system serializes the entire query object into a secure format before sending it with the action request.

• Security: To ensure that sensitive data is protected, the serialized query is encrypted before it is transmitted.
• Efficiency: This approach allows the system to accurately and efficiently reconstruct the original query when the action is executed, ensuring that all relevant records are included.

WARNING

If an error occurs during the serialization process, the "Select All" feature is automatically disabled. This safeguard ensures that the page will not crash because of a coding error. We listed a few reasons on why it might crash below.

Serialization known issues

In this section, we outline common serialization problems and provide guidance on how to resolve them effectively.

normalize

If your model includes any normalize proc, such as:

normalizes :status, with: ->(status) { status }

Serialization may fail when a filter is applied to the normalized attribute (e.g., status in this example). This can result in the error TypeError: no _dump_data is defined for class Proc, which causes the "Select All" feature to be automatically disabled.

For applications created before Rails 7.1, configuring the marshalling_format_version to 7.1 or higher will resolve the issue:

# config/application.rb

config.active_record.marshalling_format_version = 7.1

More details on normalizes documentation.