In our current Pega project, we make heavy use of the Table layout feature. Functionally, there is currently no way to determine whether a record within a page list or report definition is currently visible within the Table.

This "visibility" might be the result of a row-level visibility WHEN rule or Expression within the Table layout properties or might be the result of the end user applying one or more column filters.

There are many times when our client would like business actions to be taken on only those "visible" items in the grid rather than all of the page list records that source this grid.

I would like to propose at least one, but possibly two, new Pega-level @baseclass properties to be added that are set by the Pega framework during the ReloadSection activity for those page lists or reporting definitions used to source Table layouts. The proposed properties and their functionality are described below:

• @baseclass.pyIsRowVisible (true/false) - this new Pega property is either default to false or null for every record in a page list used to source a Table layout.
  • The Java code associated with a Section rule already determines when to show specific indices within the rendered Table layout based on either a row visible WHEN rule or expression or whether the row satisfies all column filters.
  • My request is that once the final decision is made by this code to "show" a specific page list index, then Pega would update the .pyIsRowVisible property to true for that specific page list index on the Clipboard.
• @baseclass.pyIsRowFiltered (true/false) - this new Pega property is either default to false or null for every record in the page list used to source a Table layout.
  • Similar to the pyIsRowVisible property, the pyIsRowFiltered property is only set to true if the record passes all column-level filters.

Based on current Section-level java code already being produced by Pega, it seems like a very low effort to automatically set both of these properties during the ReloadSection activity. Doing so would provide a great deal of flexibility when it comes to applying future operations on grid records.