Now that you have consumed that, here are some key points.
Official IE11 support did not start until 7.1.5
We make commercially reasonable efforts in helping customers get IE11 working in their end user portals but there are limitations.
However, we do not, and will not support Designer Studio on IE11 in PRPC. We are quite firm on that point.
So in general, your results may vary using HFixes or Compatibility view, etc in getting 6.x to run well with IE11.
The reason why you are having issues specifically with delegated rules, is that these are older form builder based rules which are not supported in IE10/11. So while I understand you are in the context of an end user based portal, you are actually effectively invoking Designer Studio based functionality. And because of that we do not support this use case.
Please reference this support article for a similar scenario. You can ignore the use of fixed portals as that is irrelevant, and a detail which does not change the evaluation.
But all hope is not lost. Obviously once you make the upgrade to Pega 7 your IE11 experience will be much smoother as you will have native support for it, including Designer Studio
Further more, beginning in 7.1.8 rule delegation has been completely overhauled to no longer expose the entire rule to the business user. Rather we only expose the necessary details to make the edits. This design change offers many benefits. https://pdn.pega.com/delegating-record
I just found out this is happening in IE9 also. We are able to do perform the delegated table updates when we login directly to the node. But the issue is reproducible while logging in through the SSO. Please advise what needs to be checked.
If this is reproducible on IE9, and only with SSO, then it sounds more security oriented and obviously nothing to do with IE11 then.
I've seen similar cases in the past where edit in excel fails only when using SSO, and it was due to the HTTPONLY setting. Something similar might be happening here.
I would diff a fiddler trace of an SSO and non-SSO example and see if anything sticks out to you. If you are not able to figure it out with your SSO team, then you can open an SR and GCS can help take a look at the traces.
Thanks a lot. We will create a SR with GCS on this.
Before that did any one faced this issue? I compare the requestors page with SSO and without SSO and not able to identify any mismatch. Please let me know if any specific property/field needs to be checked for this issue.
I have not personally come across a case like this. As I mentioned, the closest thing was where edit in excel failed using SSO. Yours appears to be the opposite in that edit in excel works fine, but editing directly within the table fails.
Also, the additional detail here is the delegated rule. Adding that to the mix I have not come across this specific scenario myself.
Upon reviewing the associated SR to this thread, it was found that the result of the analysis was an issue with the configuration of the operating environment. The solution provided was specific to the user's configuration.