Problem long description: Setting ‘Purpose’ as a source data page parameter in UI field is overriding the ‘Purpose’ parameter value based on which harness type is selected – hence causing harness fail

I used Pega 8.6.0 personal edition to recreate the issue

Steps to reproduce this issue:

1) Create a case type and enable optimistic locking(so that two users can access the case simultaneously)

2) In any step (preferably first stage and first step) configure a radio button which will take a data page list as a source with ‘Purpose’ as one of the parameters.

Note: For testing I have used ‘Purpose’ parameter only. Purpose’ parameter value is set as ‘Title’ for fetching values.

3) On the actions tab of that radio button, add post-value and refresh-this section

4) Check-in your changes

5) Create two operators OP1 and OP2 with same application access group. Login with both of them in two different browser sessions.(operator names can be anything)

6) With OP1 create a case and go to that step. Select any one of the radio button options.

7) With OP2 search that case, go to same step and select a different radio button option.

8) With OP2 submit the case. After submission for OP2, screen looks like below:

9) Now go to OP1’s session and try to submit the same case

Expectation: Case update message shown by Pega stating that same case has been already updated By OP2. Refresh the case to proceed.

Reality: Pega throws Harness fail error for OP1

Analysis: While running tracer for OP1, found the following observations-

1) At the beginning the parameter ‘Purpose’ value seemed to set as same value as we set as parameter value for the data page in UI(PFB for screenshot - you can notice the 'Purpose' parameter value set as 'Title')

2 ) Pega OOTB rule pzShowConflicts identified the conflict and set the error message on pyWorkPage(which is expected behaviour)

3 ) Now Pega OOTB Show-Harness rule, step 9(Java) is using the same ‘Purpose’ parameter to determine Harness type

4 ) Show-Harness rule got called. It looked for Harness type ‘Title’ which doesn’t exist, throwing error(HarnessFail)

Now one solution can be not to use parameter named ‘Purpose’ at all in section rule. But is there a way to restore the ‘Purpose’ parameter value so that Show-harness rule doesn't fail? There’s a ‘handleClientErrors’ activity which got called before 'pzShowConflicts'. Can we use this activity to edit the 'Purpose' parameter value?

Kindly suggest viable solutions to address this issue.

Note 1: Assume we cannot change the data page parameter name from ‘Purpose’ to anything else. Also the post-value and refresh section action items are required for that radio button.

Note 2: If similar discussion happened already, kindly refer the links in comments. Otherwise is this harness fail error expected behaviour or a product bug?