What is the correct usage of HideMessageKey in ErrorList section / How to hide property labels for error summary

User Experience
, , ,
1

Hi all,

We’ve received a recent requirement to not include the Property Label as a prefix when displaying an error summary for property-level messages in the harness.

Within the ErrorList section HTML it indicates the ability to hide error labels via the use of the “HideMessageKey” parameter. However, this parameter is not documented in the rule, the help and nor have I found anything about it in the Community.

Upon testing, it does seem to work. If the parameter is set, the property labels are hidden from the error.

–

The problem (and question) for the group is whether there is a known and correct way of passing this parameter in with a “true” value, or if there is a more sensible way of removing property labels from the error summary.

HideMessageKey is not a parameter on the parameters tab of the ErrorList section rule (which is final), and even if wrapped in another section - for example, by the existing ErrorMessageHolder section provided by Customer Service - it’s not possible to pass a parameter from a harness rule where we can name an error section (see below).

I was finally able to pass HideMessageKey by having a second wrapper section. The first one, ErrorMessageHolderInner, embeds ErrorList and has HideMessageKey as a parameter on the parameter tab. The second section, ErrorMessageHolder, embeds ErrorMessageHolderInner and passes “true” into the HideMessageKey.
This proved that HideMessageKey is effective if possible to use.

Thoughts/efficiencies or am I going about this entirely wrong?

Many thanks,
Ben

2

@BenjaminH

It sounds like you have found a solution that works for your use case, which is great! However, as you noted, the “HideMessageKey” parameter is not officially documented in the Pega platform, so there may be some risk associated with using it.

In terms of passing the parameter with a “true” value, you could try using a local variable or property to hold the value and then reference that in your section. For example, you could create a boolean property called “HideErrorLabels” and then use a “Set” action to set its value to “true” in a pre-processing activity or data transform. In your section, you could then reference this property using syntax like “Param.HideMessageKey = HideErrorLabels”. This approach would allow you to more easily change the value of the parameter without modifying the section rule directly.

Another option you could consider is to create a custom section rule that includes the “HideMessageKey” parameter as a standard parameter. This would allow you to pass the parameter directly in the parameters tab of the section rule, without the need for the additional wrapper sections.

Overall, I think the approach you have taken is reasonable given the limitations of the platform. However, if you are concerned about the use of undocumented parameters or the complexity of your solution, you may want to consider submitting a product enhancement request to Pega to request official support for hiding error labels in the error summary.