This was originally a comment on #3229, we have a work around in place to resolve the issue, but we need to revisit it.
The underlying problem is that when making an API request to invite a user, any errors from sending the email causes the API to respond with a 500 error, and only return the error in the response. On the frontend the result is that ember doesn't get a new user added to its store, but the user WAS added to the database, we just didn't email them.
The new user is getting created successfully, so the response should probably be a 201. The error could be included as a warning header, or perhaps we should include both the successful object and the errors in the response - which ought to be downgraded to a warning (an orange notification on the client side).
That is, I'm suggesting we change the API to support returning a 200/201 status with a normal resource response body along with either an errors object or along with warning headers. Which ever of the 2 we use, the result should be a success with warnings, rather than a failure.
With regard to which is the correct way to do this, JSON-API seems to now specify an errors object which matches what we have, but it does explicitly state that the errors top-level object should not be returned with another top-level object. JSON-API does not seem to make any mention of using Warning headers, so this method would at least not be a direct contradiction of the standard.
This was originally a comment on #3229, we have a work around in place to resolve the issue, but we need to revisit it.
The underlying problem is that when making an API request to invite a user, any errors from sending the email causes the API to respond with a 500 error, and only return the error in the response. On the frontend the result is that ember doesn't get a new user added to its store, but the user WAS added to the database, we just didn't email them.
The new user is getting created successfully, so the response should probably be a 201. The error could be included as a warning header, or perhaps we should include both the successful object and the errors in the response - which ought to be downgraded to a warning (an orange notification on the client side).
That is, I'm suggesting we change the API to support returning a 200/201 status with a normal resource response body along with either an errors object or along with warning headers. Which ever of the 2 we use, the result should be a success with warnings, rather than a failure.
With regard to which is the correct way to do this, JSON-API seems to now specify an errors object which matches what we have, but it does explicitly state that the
errorstop-level object should not be returned with another top-level object. JSON-API does not seem to make any mention of using Warning headers, so this method would at least not be a direct contradiction of the standard.