EZP-24851: CAPI to display server provided error message if it is sent

[janit]

Partial fix for EZP-24851, attempts to set error message to server provided one - if it is set as described in https://jira.ez.no/browse/EZP-24853:

{
    "ErrorMessage": {
        "_media-type": "application\/vnd.ez.api.ErrorMessage+json",
        "errorCode": 400,
        "errorMessage": "Bad Request",
        "errorDescription": "Value for required field definition 'user_account' with language 'eng-GB' is empty",
        "trace": "<stack trace>",
        "file": "\/home\/dp\/dev\/ezplatform\/vendor\/ezsystems\/ezpublish-kernel\/eZ\/Publish\/Core\/REST\/Server\/Controller\/Content.php",
        "line": 248
    }
}

[andrerom]

cool :)

[andrerom]

ping @dpobel this is about to become part of customer request (issue).

[dpobel]

This change is not really needed because even in case of error we always provide the response object where the error message is available (like any element in the response). So basically, in your callback you can always write something like:

contentService.loadLocation(locationId, function (error, response) {
    if ( error ) {
        console.log(response.document.errorMessage.errorDescription);
    }
});

[andrerom]

but isn't something ala what proposed here about making sure it always displays in the dev toolbar?

[dpobel]

@andrerom not sure to fully understand your comment. What is "the dev toolbar" ? As far as I know, the CAPIError message is not really used any where.

[andrerom]

network tab in browser developer tools, the only place to know what goes wrong with this next gen UI ;)

[janit]

The CAPI error message can pop up as a fallback. In this specific case when developer validating on server side, it fails and shows the standard error message - even though the response contains the errorDescription in JSON that could be displayed.

[dpobel]

network tab in browser developer tools, the only place to know what goes wrong with this next gen UI ;)

ahah :) but the network tab only cares about the actual server response, not how we create an Error object and so on. So this patch does not change anything there.

The CAPI error message can pop up as a fallback. In this specific case when developer validating on server side, it fails and shows the standard error message - even though the response contains the errorDescription in JSON that could be displayed.

where does that happen ? if it's in PlatformUI, this should be fixed there as choosing the error message from the Response (or building the message differently) over the one provided by the Error message is an app decision, not a REST Client decision.