Apex Code Development You need to sign in to do that
Don't have an account?
Internal Partner How to test critical update "Add a Namespace Prefix to Query Parameters and pageReference.state Properties"?
Hi all,
there is the critical update "Add a Namespace Prefix to Query Parameters and pageReference.state Properties", where we don't know how to test. What does Salesforce mean with it? an example?.
there is the critical update "Add a Namespace Prefix to Query Parameters and pageReference.state Properties", where we don't know how to test. What does Salesforce mean with it? an example?.
Well, I figured out that it breaks some of my lightning pages by removing a whole bunch of paramaters from the URL, however all of my code is unmanaged and written in the Sandbox so... Found this trying to figure out the same thing you are - what the heck is this supposed to do?
All I can tell is that it breaks my lightning pages where I pass parameters in the URL and then handle them in the javascript controller.
(I can't edit my comments... awesome!)
Just wanted to point out - I would expect this to matter when dealing with doing something with query parameters inside of managed packages. Namespace prefixes should be irrelevant to my code since It's my own unmanaged code and not part of a managed package. This feels like a bug to me, however if I try to report it Salesforce is going to tell me to come to the developer forms and post my question here. This is the only other related question I see to this critical update so just wanted to post here as well and say +1 on the question. I don't know what the intetion of this update is and it appears to break unrelated things in my org at least when I flip it on.
@chris - thanks for reminding me about this. I basically ran around the internet for a few days trying to figure this out and never came back here to update. Let me link to the stackexchange where I had a little more convo going:
https://salesforce.stackexchange.com/questions/237189/critical-update-bug-add-a-namespace-prefix-to-query-parameters-and-pagereferen/237208?noredirect=1#comment362372_237208
And if you don't feel like reading a whole lot, here is the short(ish) version:
When using the "e.force:navigateToURL" action in a lightning component, all of the query parameters without a "package prefix" get stripped out. This applies to managed packages as well as unmanaged code. Really though, all this is doing is checking for a double underscore, "__", attached to the query parameter. So a custom field "Custyfield__c" for example would actually be fine since it contains double underscores. This might come into affect in other places as well besides "e.force:navigateToURL" - maybe any page navigation to or from a lightning component. I only really tested the stuff that was breaking in my org which was navigating from one lightning component to another.
(Short version over - now some lengthy examples!)
Here is an example that was basically my situation - if I'm navigating to some lightning component called "MyPage" from a Lightning component and passing parameters "Name" and "Quantity" and my URL looks like
"/one/one.app#/n/MyPage?Name=joe&&Quantity__c=4"
The Name parameter is going to get stripped out and when I land on the new page my URL will be rewritten to
"/one/one.app#/n/MyPage?Quantity=4".
If you're depending on that Name param being there, this would obviously cause everything to break. The solution that salesforce eventually recommended (and that we had already figured out in our stackexchange discussion - thx Ralph) is to add a prefix to all of your params. So,
"/one/one.app#/n/MyPage?c__Name=joe&&c__Quantity__c=4"
would work just fine and nothing gets stripped out.
Unfortunately for me, I was proccesing field names in my destination component and I need the param to be the API name (c__Name isn't going to work very well if you try to update that field) which means I had to add a prefix into every field and then strip it back out. So, in closing, this critical update pretty much doesn't do anything relevant to me other than break all kinds of stuff in my org which I then had to hack in some nonsense workarounds to fix (adding fake prefixes to every field in the URL, then stripping the prefixes back out in the destination code. Yikes.).