In short, the issue was that

 stockMovement.sourceType = params.sourceType as RequisitionSourceType

was assigning a null value to the sourceType because params.sourceType is null, and also because it is a value from the requests body and not a param.

Although it looked like all I had to do was change params.sourceType to request.JSON.sourceType as we have done before, I noticed that when using the "inferred data binding" like

def create(StockMovement stockMovement) { ...

we lose access to the requets.JSON data.

I did an experiment and removed the StockMovement stockMovemen from the parameters and after that, I had access to request.JSON data.
Just wanted to point this out, not sure if it was already discussed/noticed in my absence and if someone knows what's up the let me know.

cc @awalkowiak @kchelstowski @alannadolny @jmiranda

@drodzewicz Good catch! Yes, the request.JSON object cannot be accessed twice so once the data is accessed in the command object binding (i.e. populating the StockMovement object), then we're done. The best solution might be to include RequisitionSourceType as a nullable property on StockMovement so it gets bound properly.

To make it backward compatible, we'd need to figure out what was going on in Grails 1. I don't expect this to be true, but maybe it was adding all request.JSON to params so you could access it in either way.

Nevermind, it looks like RequisitionSourceType is already on StockMovement, so just removing that line (as you did) should take care of the issue. Nice work, guys.

this is because parseRequest: true doesn't work anymore in Grails 3 (or even in 2), so as you said -> changing params to request.JSON should be done here, but since you are binding the data in the params, you "lose' the access to that and this is expected behavior, so LGTM

Boom goes the dynamite. Thanks for the reminder @kchelstowski.