SA-4402

Summary

User have a Grid Repeat which uses a custom Pagination activity. Pagination activity handles both Pagination and filtering. On Filtering the grid column the results are getting duplicated by an OOTB prpc activity.

Error Messages

incorrect results shown on screen. incorrect pxResults count

Steps to Reproduce

Are mentioned in detail along with the screenshots in the attached doc.

The same can be found here:
1. Launch the Field Marketing Portal using the below access details:

2. Open one of the Campaigns from My Campaigns
3. Click on the Edit link for Campaign Contacts(2nd Row)
4. Now Click on the Filter Icon on the EMAIL column
5. Filter by [email protected]
6. Expect Count after Filtering is 8 - Which is correct
7. But the Grid results shows 16 records and Clipboard page is also having 16 records which is incorrect

Root Cause

The root cause of this problem is a defect in customer application code/rules. It was found that a custom pagination activity was used for progressive load on the repeat grid. The pagination / sort activity does not fetch all the data / records at once.  With each call it enables pagination and configure the page size to their desired viewing size. 

The custom pagination activity is not written in a way that supports “progressive load” and was different from @baseclass.pzGridSortPaginate in terms of the behavior. 

Resolution

Local Changes suggested: 
Changing the pagination mode of the grid is one way to resolve the issue. Modes: Page 1,2,3 ; Page 1 of X work well with the custom activity that fetches all records at once. But, results are displayed in pages. This change should be made in  section PegaMT-Work-Campaign. ContactListViewerManual. The other way to resolve this is to change the custom pagination activity to support “Progressive Load”.

Solution:
Developers were able to resolve this issue based on the brief description on how “Progressive pagination” currently works in PRPC. In the second call to our activity user were not setting .pyPagingSettings.pyPageIndex on the report param page, which previously was not required.  In a similar manner developers are now required to set Param.currentPageIndex = 1 after a filter because it is no longer provided for the first call to our pagination activity ( causes our thread to hang ).