Currently the remote services pass back the error message key for remote attribute validations and then Rice resolves them. However, with truly remote service this will not be possible as the local rice instance won't be able to resolve remote service. Instead the actual error message that is being displayed to the user should be passed back from the remote service.

Claus: Back to my question, does the error builder of RemotableAttributeError support error message with arguments (ie "This error

!")?

Eric: no it does not and it's not supposed to, the idea being that messages will be resolved from local resource bundles before passing them back across the wire

because say an application like kc was producing error messages, it would likely have some external message bundle for i18n, but it should resolve those outbound error messages prior to sending them to rice (in the case of this coming from something like an ActionTypeService, AgendaTypeService, whatever) because Rice has no idea about KC's local error message information and shouldn't need to

Claus: So you are saying the remote service will send the actual error message that is displayed to the user? Because that's not what's happening currently. KRMS is setup to accept an error message key (i.e. peopleFlow.peopleFlowId.require), not the actual error message. KRAD (in ErrorsFields.getMessages()) then looks up the actual message (i.e. "PeopleFlow ID is required.") from the appropriate ApplicationResources.properties file (in this case KEW's).

Eric: yeah, that's not the way it should be working, peopleflow comes from kew, so we should assume that KRMS should not even have access to kew's ApplicationResources.properties

in practice it does because our current modularity sucks

but imagine that KC was creating a custom action type in KRMS

we won't have their ApplicationResources.properties available to us on the KRMS side

so if we are getting error messages from a RemotableAttributeError, they need to be pre-resolved

now, on the KC side in that case, they would probably do something similar to what you are doing in order to resolve the actual error message before sending it across the wire

does that make sense?

Claus: Uh, oh! We'll need to fix that then before the release. There is the KRMS part and the remote services we'll need to fix. I'll create a Jira for it.

It makes sense and I understand it.

Eric: cool, yeah we can just treat it as a bug