I have created a sample app in developer org and set the class modifier as global and then released its final version as managed package. Now it was caught in security review , now I have to make it Public. When I edit it and try to save it, it shows me error Cannot change it back to public. Any solution to this?
1 Answer
Create a differently name public class and move the global class logic into that and convert your internal code to use that public class instead. Then:
- attempt to delete the global class but based on the special mention of global in Deleting Components from Managed Packages I suspect that can't be done
- add the @deprecated annotation to the global class (but if the code is pushed into non-namespace orgs as part of your development process that won't be possible as it will stop the code compiling in those orgs)
- empty out the methods of the class (so the class doesn't add much to your untested line count) and add a comment explaining that it is no longer used but has to be kept because of the packaging issue; you could also add a throw of an exception with an explanatory message to each method
Alternatively you could move all your code to an org with a different namespace and so be able to cleanup as you please. But that is only practical if the package isn't already in use and isn't too far into processes like the security review you mention.
-
-
1@susanoochidori Perhaps. I recollect some discussion that if a managed package was not in use support could "fix" what could normally not be changed. But that process may take several days to get through. Occasionally leaving junk in your managed package is pretty hard to avoid in the long run so being resigned to that is the pragmatic approach. (Not sure why you mention "patch org" in your question; patch orgs can't violate patterns established in the org they come from.)– Keith CJun 19, 2015 at 12:25
-
-
1@DavidJ If versions of your managed package with the global classes in it are installed then AFAIK yes you can't remove the global classes. But a process that worked for us in a similar context was to 1) uninstall the package versions everywhere they were installed and 2) get Salesforce to set the package versions back to beta status and 3) remove the problem component then 4) create a new released package then 5) re-install. Probably impossible to do if you have any live customers.– Keith CJan 18, 2016 at 20:38