As of Summer 14, there are 2 new objects which allow you to use SOQL to see which users are licensed for particular Managed Packages: PackageLicense and UserPackageLicense.
UserPackageLicense lets you see which users are licensed for a particular package:
String APP_NAMESPACE_PREFIX = 'skuid';
List<User> licensedUsers = [
You have to use the namespace to reference a component in a managed package. Just changing the code in the subscriber org should work. Here's the modified version you'd want to use (change packageNS as appropriate):
Although this post is from last year, I would like to address it since it's apparently coming up in search results for those looking to post unmanaged packages to the AppExchange, and the main answer currently features out-of-date info.
To confirm, unmanaged packages are not accepted for security review or posting on the AppExchange.
I've put together some ...
I'm pretty familiar with the Metadata API and deletion of Package 'definitions' is not supported presently it appears. The only thing i can think is accessing the Delete action via the page URL's, which is not ideal of course since its not supported.
I did also try this in destructiveChanges.xml, it did not work sadly. I should clarify, it did not error, ...
It cannot currently be done by you. Perhaps Salesforce support could do it if you contacted them.
You can uninstall the package from various orgs as suggested by the previous answer. That does not eliminate the package from your package list.
... will still show the package even if it is uninstalled from all orgs.
I have created ...
There are already some open sourced tools for this task .One of them is as below
You can also use eclipse to the do this .In eclipse once you selected compoenents and fetch the package xml file is formed .
Go to Setup > Customize > Home > Custom Links
Create a new custom link to your VF page (eg /apex/ns__pageName)
Edit your package and specify the custom link
Now a [Configure] button will appear after install. Guide your users to click it.
Salesforce does not allow unmanaged packages to be part of appexchange .You will have to convert them to managed packages .
You can publish your apps as managed package to the appexchange provided you sign up as partner.Do not confuse that partner has to be some consulting firm .Anyone can be a partner Even as a solo developer you can be a part of ...
A custom app in Salesforce is not the same thing as an AppExchange app. A custom app is:
An “app” is a group of tabs that works as a unit to provide
application functionality. Salesforce provides standard apps such as
Sales and Call Center. You can customize the standard apps to match
the way you work.
So, essentially, a custom app is just a ...
Take a look at An Introduction to Packaging:
Implications of Managed Packages on Source Code
If someone installs a managed package, they don't get access to all the source code of that package. For example, if the package installs an Apex class, they will not be able to view the source code of that Apex class. Here is a list of factors that should be ...
One viable alternative is start converting the profiles into permission sets as a part of the DX move .
With permission set you can easily group them with relevant objects .
Salesforce did a blogpost on this and you might find the blog helpful.
I believe there is a case where a package does not have an uninstall link which has nothing to do with dependencies. If the package is a subscription from the AppExchange, I believe you have to cancel the subscription in the checkout page before you can uninstall.
Navigate to the Salesforce AppExchange website: https://appexchange.salesforce.com/
I have never tried this before. But using dynamic objects you can do this. Here are idea to get you started.
Store the package details and object, field in some custom setting or custom label. Now make a dynamic SOQL to query package details. If you found the details then create dynamic instance of sObject and create new record of it. As you are not direct ...
Where do you actually create the package for the shared classes? I created it in a scratch org like the docs said. But what happens when the scratch org is deleted due to expiration
Packages are created in the DevHub org, so they won't be deleted with a scratch org.
I cannot promote the package version as it says I do not have the required permissions. ...
Generally, is it possible to install two unlocked packages that share overlapping Metadata, e.g. the same custom object?
One would need to be a dependent of the other if the exact same metadata exists. Note, however, that a custom object has many related components, which of which may be unique. For example, you might have a custom object, and a dependent ...
The link from @xedshot (https://help.salesforce.com/articleView?id=distribution_perm_sets_profile_settings.htm&type=5) is correct and relevant, but I feel that it's worth quoting and explaining the relevant section:
The following list is given under the title "What permissions and settings are included?" for Permission Sets:
Assigned custom ...
When you run this code in your original environment, it's finding the RecordType that you had manually created in that org. You'd get the same result both running the test and running the code in the console.
Packaging and deploying to a fresh organization without that RecordType fails if it hasn't been included in the package or manually created beforehand....
Here is what you need to do:
You need the ability to fetch the metadata details from the org. If you want to do this in Apex, you might want to check out the Apex Wrapper Salesforce Metadata API.
Here is the complete steps for app exchange publish
So here are the steps. I numbered each step because the order is fairly important - in most cases, you cannot move forward without completing the previous step.
1) Create a Dev Org
This is the org you use to develop your app and create the initial app packages. If you haven't done this already, you can ...
There are certain situations where Salesforce will not allow you to uninstall a package because it could interfere with a part of the system that is not being deleted. I've list a few scenarios straight from Salesforce, where an uninstall option is not available.
-You can’t uninstall a package whenever any component in the package is referenced by a ...
When creating a managed package, prior to uploading you need to have test methods that meet the 75% coverage while in the packaging org. If they pass the managed package can be created
So the answer is yes
When installing in the destination org the tests are not run and are not required or expected to pass since configuration in destination orgs vary.
Don't worry about coding defensively against your client's configuration; they're allowed to ignore certain types of test failures. This is noted in the documentation:
If a subscriber creates a validation rule, required field, or trigger on an object referenced by your package, your test might fail if it performs DML on this object. If this object is ...
This is a known issue and we have an item in our roadmap to fix this so that apex code in namespaced unlocked packages is visible in installed orgs. The side effect of this is that it is difficult to work with debug logs in this scenario.
My suggestion is to explore (until we fix this) no-namespace unlocked packages. In a no-namespace unlocked package, Apex ...
There are two things you have to do:
enable Translations in your Scratch-Org-Def (I guess, you already did).
let package-version-create use this scratch org def (I guess, that you didn't)
So you scratch org def should looklike this:
On our product roadmap, we have plans to support installing and upgrading multiple packages in a single transaction.
Until that is available, would this multi-step process work for you?
1) Release Package A ver 1.1.0 that has both the methods - global static void doFoo() and global static void doFoo(String msg).
2) Release Package B ver 1.1.0 where doBar(...
You can use package.xml to control what will wind up in your package. The trick is to specify only a fullName element in the package.xml which will cause the deployment to put the metadata into your org as members of the package.
We use this setup for deploying code to our DE orgs and our packaging org. It ensures that whatever a developer was working ...
A key factor in assembling a package is how components depend on each other.
In some cases the dependency is such that component A (e.g. a Visualforce page) can't work without component B (e.g. its controller class). For those cases, the platform's packaging tools automatically follow the dependency chain and include the necessary components which is good.
No, this isn't possible. You can set an InstallHandler to create data, deploy a metadata file, etc. Generally, though, any other actions you will want to take should be either (a) documented in a post-installation doc, or (b) set up as a Visualforce page that the administrator should visit after installation. You may want to submit this as an idea on the ...
Thoughts. As has been pointed out the UserInfo.isCurrentUserLicensed is of course for the current user, and since you can only impersonate users in a test context your out of luck here. I've had a look through the Salesforce API documentation to determine if there is any query able metadata about this and I didn't find any. I also considered the Metadata ...