10

A custom button in a managed package uses a protected custom setting in the same package to retrieve a namespace:

/apex/{!$Setup.Constants.URL_Namespace__c}PageName?param=value

When installed with namespace PKG, this looks like

/apex/{!$Setup.PKG__Constants.PKG__URL_Namespace__c}PageName?param=value

This used to work in both classic and lightning before Spring 2020. With Spring 2020, it instead produces an error message:

Page PageName does not exist

When logging in through subscribers access, the button correctly redirects to the appropriate page. A Base64 decode reveals

{"componentDef":"one:alohaPage","attributes":{"address":"https://orgname.lightning.force.com/apex/PKG__PageName?param=value"},"state":{}}

When logged in directly, the redirect drops the namespace and instead goes to:

{"componentDef":"one:alohaPage","attributes":{"address":"https://orgname.lightning.force.com/apex/PageName?param=value"},"state":{}}

It also works well when another managed package "PKG2" has a protected custom setting and a button used for the same purpose, targeting the page from package "PKG".

The only scenario where it does not seem to work is when the button, the custom setting and the target page are in the same "PKG" managed package.

I thought it may be related to Require Customize Application Permission for Direct Read Access to Custom Metadata Types or Require Customize Application Permission for Direct Read Access to Custom Settings critical update, so I tried turning the following options off in Schema Settings:

  • Restrict access to custom settings
  • Restrict access to custom metadata types

I've also confirmed that the profile has the following permissions:

  • Customize Application
  • View All Custom Settings

What else can I try?

  • Is the custom setting protected? That seems to be the only scenario where I am hearing this fails. I just tested a similar button in our package in a preview org and I'm not seeing this happen. – Charles T Jan 14 at 15:51
  • @CharlesT Yes, the custom setting is protected. – ipavlic Jan 14 at 16:33
  • 2
    OK that may well explain it. I don't have this issue with an unprotected custom setting. Since all you are doing is merging in a namespace, which is not high-security information, you may want to refactor this usage to an unprotected setting. – Charles T Jan 14 at 18:02
  • 1
    Also note. This has been a problem on and off over the years - API 31.0 breaking change in namespaced Visualforce $Setup global. It's a pain for running multiple dev orgs if you don't want to tie them to the same namespace, but I've found hard coding the namespace into the $Setup reference to be reliable. – Daniel Ballinger Jan 16 at 19:51
  • 1
    This happens to us as well but only in Lightning. In Classic it is working which is why I thought it should not be related with access issue. Still we tried to add access for protected custom setting in one of our permission set but it did not do the trick. – tugce Jan 22 at 12:51
0

I also have this issue and it does seems related to the critical update you referenced. Possible that the protected custom settings fail somewhere between, because SF require now that you will specifically grant each profile access to each custom settings, but you cannot grant subscriber profile access to protected custom settings.

I hope SF will refine this update, but since I didn't want to take the risk, I move the namespace prefix to custom label and it worked.

/apex/{!$Label.NamespaceLabel}PageName?param=value

So far notice it only in LX mode with custom button but in case it will be enforced also in apex, then might need to move additional custom setting to different implementation. 1 option is to use public custom setting.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.