Skip to main content
Tweeted twitter.com/StackSalesforce/status/1087455019467718656
deleted 1 character in body
Source Link

Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.

While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).

Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like

@AuraEnabled
public static string myMethod(String myBoolValue)

with the Aura call

var action= component.get("c.myMethod");
removeAction.setParams({
    "myBoolValue": true
});

Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.

From what we can see, that change isn't tied to a Critical Update.

While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.

Would it be possible for Salesforce to be backwards compatible ? Seems like we won't be the only ones to have that issue and Salesforce isn't really knownsknown to introduce breaking changechanges (or at least, not force a breaking change).

Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.

While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).

Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like

@AuraEnabled
public static string myMethod(String myBoolValue)

with the Aura call

var action= component.get("c.myMethod");
removeAction.setParams({
    "myBoolValue": true
});

Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.

From what we can see, that change isn't tied to a Critical Update.

While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.

Would it be possible for Salesforce to be backwards compatible ? Seems like we won't be the only ones to have that issue and Salesforce isn't really knowns to introduce breaking change (or at least, not force a breaking change).

Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.

While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).

Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like

@AuraEnabled
public static string myMethod(String myBoolValue)

with the Aura call

var action= component.get("c.myMethod");
removeAction.setParams({
    "myBoolValue": true
});

Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.

From what we can see, that change isn't tied to a Critical Update.

While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.

Would it be possible for Salesforce to be backwards compatible ? Seems like we won't be the only ones to have that issue and Salesforce isn't really known to introduce breaking changes (or at least, not force a breaking change).

Source Link

Value provided is invalid for action parameter [VAR] of type 'String'" instead

Seems like upcoming changes in Spring 19 are causing us issues with "AuraEnabled" methods. Since forever now, primitive types were sent from Aura to APEX as String only as explained here: https://salesforce.stackexchange.com/a/245733/42188.

While the change explained in the previous post is beneficial (parsing primitives), it breaks older setups (or older manage packages).

Let's assume you had a Lightning component sending a boolean value to an APEX method. The APEX signature would've look like

@AuraEnabled
public static string myMethod(String myBoolValue)

with the Aura call

var action= component.get("c.myMethod");
removeAction.setParams({
    "myBoolValue": true
});

Since the boolean value sent by Aura is now correctly parsed as a bool (previously, it was sent as a string), APEX now returns a "Value provided is invalid for action parameter myBoolValue of type 'String'" instead" error for the same code.

From what we can see, that change isn't tied to a Critical Update.

While the "fix" is pretty simple (just change the apex signature to accept a bool instead), this isn't really an option for ISVs with multiple managed packages installed everywhere that will just "stop working" when the Spring 19 rollout will be completed.

Would it be possible for Salesforce to be backwards compatible ? Seems like we won't be the only ones to have that issue and Salesforce isn't really knowns to introduce breaking change (or at least, not force a breaking change).