14

You need to prefix the My_Batch with the namespacesprefix of the package: [namespace].My_Batch b = new [namespace].My_Batch();


14

Unfortunately, you have your answer right there, beta packages can't be upgraded. You will have to uninstall to get to the latest version. SFDC should help you restore your managed package data (in the installed package page) to help you restore your data after the re-install process has completed. However, if your data structure has changed very much ...


9

Debug logs raised from within a managed package are not exposed within the installing Org by default (Since Winter '12). This includes beta managed packages and full releases. See Logging from a deployed managed package. You now need to use the LMA (License Managing Application) with the managed package to log into the Org and see the debug logs. See ...


7

Salesforce support has tools to undo a managed package release. They do this by converting you "managed - released" package into a "managed - beta" which undoes the locking with newly added components. There is one major prerequisite before they can do this: the version you want to un-release needs to be uninstalled from ALL organizations. This can pose a ...


7

No, you can't package any standard fields, including standard value sets. Only this list of components is available for packaging.


6

Jordan, I've used webrat and / or mechanize to do this in the past. If you'd like I can help you kick out a script to do it.


6

I created an installer driven by Selenium WebDriver, which is available here: https://code.google.com/p/force-managed-package-installer/


6

I've created several cases on this problem in the last few weeks. Although I personally don't like the answer, one eventually came back from salesforce support that "at present there is no SLA on the installation process". There are a few more details here Managed packages can take hours to become available. I guess the next step is to find another channel ...


6

Such error messages represent internal platform failures (or gacks as they are sometimes known) rather than anything in your Apex code, this is why your Apex Exception User is not receiving anything. The underlying reason could be a range of things, a bug in the platform code or an error relating to a feature or incompatability in the org your trying to ...


6

Solution: one InstallHandler class to rule them all We create separate install handler classes, each of them taking care of a single responsibility (ie: create custom settings, upgrade to a new data format, create some default records). They all implement the InstallHandler interface, but they are public as opposed to global. Then we have one main ...


5

One of our developers Chris Peterson has a case raised with Salesforce 09290363, in it he is currently discussing with the support team if it is a bug or not. Our feeling is it is a bug and agree with you though it maybe an edge case in some respects, it also could be quite tricky to get out from, especially if the duplicate name was introduced as part of an ...


5

My first reponse was to laugh at your pain because it so closley resembles mine, but then I made myself sad. You are 100% correct! Once you have a beta managed package installed the only way to install another version of the package in question is to uninstall the current version and export and reimport all of your data in the process.


4

There is a Known Issue regarding getting rid of the code lock from Scheduling: http://success.salesforce.com/issues_view?id=a1p30000000STwPAAW . See if this is your situation.


4

Installing beta package releases into production orgs is not possible except in very special cases (the "production" orgs created via the partner portal), so the answer to your first question is almost always no. For your second question, you can bypass the appexchange if you want, and distribute your app directly via it's install link, certainly. If you ...


4

The Connected App provides a way for you, the ISV, to obtain access to a customer's org via oAuth. If you follow the flow here, the customer would click on a link/button provided by your package that would ask them to authorize your app and direct them to an endpoint where the oAuth process provides you, the ISV, with an authorization code. You then use that ...


4

We are experiencing this same issue again: This issue happens if: 1) The package is recently created (give it a few hours to propagate to all types of instances and might be between 2 to 24 hours) 2) If you are in the middle of the Major release schedule. https://trust.salesforce.com/trust/maintenance/ (Some orgs are upgraded early for eg Winter 14 release ...


4

Try this it will work for sure. First keep the scripts and style in a separate tag. Second for namespace use like this; for stylesheet we can use <link href="/resource/namespace__resourceName" rel="stylesheet"/> <ltng:require script="/resource/namespace__resourceName....."/>


4

I'll start with a quick acknowledgement that you want to do this directly in Apex. I don't think this is currently possible. With the right API call it might be possible to access that information with a callout from Apex... At first I thought you could use the Metadata API to query the InstalledPackage Metadata via the Apex Wrapper Salesforce Metadata API ...


4

I ran into this today, it looks like it is popping up again recently. I can't offer any science but I did get past it. If it's happening to you, try deleting all code in the offending component (between the component tags but not the tags themselves) and then upload the package again, fingers crossed and you will get no error. Then paste the same code back ...


4

you forgot to use @namespaceAccessible annotation, in order to make public class accessible across different packages in one namespace. Here is a documentation The @namespaceAccessible annotation marks public or protected Apex in a package as available to other packages with the same namespace. Unless explicitly annotated, Apex classes, methods, ...


3

The error message here seems to suggest that OTHER_PKG is in fact a beta release of that package. If true, salesforce is doing you a favor by blocking this as building an extension package off of a beta release would mean that you are forever locked into that specific version of the package. Why? You can't upgrade beta packages. You can't uninstall a ...


3

I've done it in the past with a screen-scraping approach, using (separately) Selenium, Watir, and JWebUnit. Also used it for automating deployment of metadata not supported by the API (e.g. time-based workflow rules, some of those little annoying checkbox settings, common configuration clicks, etc). Watir would be my first choice if I wanted something more ...


3

No, User Interface settings are not available in apex, nor are they even available through the metadata API. The only configuration option here is to set them through the Salesforce UI. EDIT: The one lever that you do have around Salesforce configuration in your customer target org is setting up Package and Object Requirements when uploading your package. ...


3

Per the following documentation, you can delete Custom Tabs from a released managed package. http://www.salesforce.com/us/developer/docs/packagingGuide/Content/packaging_managed_component_deletion.htm There are a few considerations: Once you delete a tab, you cannot create another tab with the same name so you'd have to rename the tab to make it point to ...


3

Yes, you can switch a never-production-uploaded-global back to its previous access level. You'll only be committed to it if you upload it as a production version. You can also enable "managed package debugging," which allows you to get the same debug logs you'd get as if the code were not in a managed package. This feature only works when using the ...


3

You can get away with the problem of namespace in your lightning components by crafting your own wrapper class structure for your data attributes. The blog post here describes how to create message or wrapper class https://medium.com/@mohitkumarsrivastav/transitioning-from-a-visualforce-developer-to-a-lightning-developer-c23c269157bf#.jviqi965l So in ...


3

when you need to publish final managed package you need to check checkbox "Managed - Released" while uploading the package.


3

What are the repercussions of moving from managed beta to managed release ? The restrictions depend on what you're talking about. For example, objects and fields can't be renamed, fields can't change data types, global classes can't be renamed, and so on. Specifics for each type of data are mentioned in Components Available in Managed Packages. What ...


3

For your point first thats not possible. You need to first uninstall that package first. For second point you can take a offline backup in Eclipse and then remove dependency of your Beta package and then reinstall again. And in end from backup create the fields and update the components. But every time you try to install the package you need to run this ...


3

Never mind, I found it: https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/packaging_metadata_in_apex.htm, Specifically: Managed packages not approved by Salesforce can’t access metadata in the subscriber org, unless the subscriber org enables the Allow metadata deploy by Apex from non-certified Apex package version ...


Only top voted, non community-wiki answers of a minimum length are eligible