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 ...
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, ...
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 ...
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 ...
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 ...
Never mind, I found it: https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/packaging_metadata_in_apex.htm,
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 org
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"/>
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 ...
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 ...
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 ...
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 ...
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 ...
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
So in ...
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.
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 ...
There are two different things here.
Beta Versions of Managed Packages(These can be private manage packages or App exchange managed packages. Private one's doesn't need to go through security review. EX: You can work with a vendor to build some functionality specific to your needs and they can do it as a private manage package for you.)
AppExchange Security ...
There is no magic scripts available to strip of the namespace from the aura components.
I usually instruct developers to not use the namespace in code and work towards making components completely namespace independent .
Even if they have to hard code namespace do not use it everywhere. Just have it in common place where one could change it later easily .
This part of your error messages to me suggests some kind of platform bug or corruption in your Packaging org, for which i would strongly recommend you contact Salesforce Support on before trying anything else. As you say its quite odd that this occurs on read as well.
Failed to process the request successfully. Cause(UNKNOWN_EXCEPTION): null:
As Bob said, have you tried:
IF(Account.Id!=NULL, "aid="+ Account.Id+"&", "") +
IF(Contact.Id!=NULL, "cid="+ Contact.Id+"&", "")
This of course will mean that your button no longer works in your package dev. org(s) as the namespace is not present there.
I'm not sure there's an elegant solution for ...
This is a really subtle shortcoming of Permission Sets and Profiles. Go and vote on the idea now!
If you truly need to automate this, it's not impossible. You could stage up a page with the correct checkboxes selected with some URL hacking and send that back to the user like the following example:
InstallAppController.cls (use API 31.0 or app returns 0DS ...
An OEM package is basically the same thing as a normal managed package; OEM vs. ISV is about who's providing licensing. With the OEM licensing model, you create contracts with salesforce.com for the licenses, and your clients create contracts with you. With the ISV model, users already have a salesforce.com contract, and form a separate licensing agreement ...
Note that the framework doesn’t currently support the $...
One should be very careful removing components once a Managed Package has been release .The exact behavior you are facing has been documented here
To get back the Undelete Action you will need to log a case from your partner portal and request the undelete link .
You will have to uninstall the BETA package and there is no other alternative here.
Things to keep in mind
1.All the new fields you created on the managed objects will have to be deleted to allow uninstall
2.If you have added validation rules ,workflows or any other customization on top of managed package needs to be deleted and recreated
3.You should ...
It looks like you are trying to use the tooling api to dynamically update a managed package component in the subscribers org. That isn't possible. As you found, components of a manged package can only be updated in the packaging org.
It's the same general idea as the subscriber org not being able to update the components.
I was not aware of the inability to remove flows (1GP beta), so thanks for sharing. However, I believe you are misunderstanding what this means. I believe this is simply saying that flows from 1GP or 2GP managed packages are not subscriber deleteable, rather than set in stone within the package itself when using betas.
In terms of other beta "gotchas&...