19

I'm facing a major problem is critical stage of my project:

I have packaged my app in a managed package (currently beta), including 5 custom setting objects, 2 of which are Protected. The 2 protected objects were not installed. Does anyone know why? In an attempt to move forward I manually copies the two objects into the org (via the IDE), of course these have no namespace. Now some of my code that refers to these object does not work and I don't know if this is because the objects are Protected or because of the namespace .

Any suggestions for these two problems are much appreciated

Thanks

  • I've been through this pain: unfortunately "protected" is the default visibility but for managed packages a visibility of "public" is generally what you want. The setting are then visible and editable in the org the managed package is installed in. – Keith C Nov 11 '12 at 13:21
18

As you say, installing the custom settings outside your managed package won't work as they will be in a different namespace.

Assuming that your protected custom objects are included in the managed package, ensure any of the fields for them are also included. This should happen automatically when they are referenced by your Apex code.

If Privacy for a custom setting is Protected, and the custom setting is contained in a managed package, the subscribing organization cannot edit the values or access them using Apex.

You can only work with your protected custom settings from apex code within your package. You won't be able to manipulate them directly via the settings page.

12

Actually, they most likely are there. It's just that you can't see them because they're protected. Your managed application can see them, but you can't (when installed in another org).

You might expect these protected custom settings to be visible yet their data to be hidden, but actually the custom settings themselves are hidden from view, making it appear as if they didn't get included in the package when in fact they're really there but invisible.

If your package references them (or anything for that matter), it's impossible for them to not get included in the package. If, however, no components in your package directly reference them and yet you manually added them to the package, then they will be invisibly deployed to the org and effectively unusable since they are protected.

4

Packaging. Custom setting objects are packaged if you either explicitly reference them in your packaged Apex code or if you explicitly add them via the Package UI. You will need to do the later if you use Dynamic SOQL to access them.

Visibility. In addition to code, Protected custom settings are infact available via the standard Custom Settings UI. But only if you are logged into an org with your package installed via the Subscriber Support feature. So it is likely your custom settings did get packaged, you just could not see them. Note however for this you have to have Aloha enabled for your package (which requires a Security Review). Search SF help for Subscriber Support for more info. Alternatively I've seen some packages have provided VF admin pages for updating protected custom settings via the Package Configuration link.

Broken Code. Regarding your code that is not working. You cannot change the visiblity of a Custom Setting once created from the UI, even if you have not packaged it. However if you are at a Beta stage you have the option to delete it and recreate it. This will require you to unpick / comment out references to it while you do this. But is by far the best way than having to live with the confusion of your devs, users and support teams etc.

  • Thanks Andrew for explaining the visibility piece in detail. I actually want to have a protected CS in my package, and would like to update it every 6 months in subscriber org. From what you say, all they have to do is, grant me login access and I can see that CS and update it as well. I do not want them to update it. regards Mitesh – Mitesh Sura May 1 '13 at 13:50
  • That is indeed correct! :) – Andrew Fawcett May 1 '13 at 15:47

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.