Well let's take a look at your deploystage directory
So, this is really interesting. There are two things that pop out right away.
Firstly, it looks like our package.xml file wasn't set up correctly to begin with. The following section:
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):
I have something similar in a package I have built - a series of apex classes that make callouts to a third party web service. The expectation is that a customer will then build their own VF controllers to utilize my classes, and the data they return. To get round the issue you raise, I built a globally available method in a class in my managed package that ...
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 might also be interested in this Apex Enterprise pattern we presented at Dreamforce this year. If you follow the Selector pattern to manage your database query code. It automatically handles multi-currency for you in the SObjectSelector base class. Useful to ensure during your development process no hard references slip into your queries without you ...
Your right James, you need to use dynamic SOQL and to test the org for a presents of multi-currency related fields.
For example, wrap your methods that reference multi-currency objects in a check for an element that is only available in orgs that have multi-currency enabled (I'm using DatedConversionRate here, but there might be a schema type that is more ...
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, ...
Does your post install script have with sharing in the class definition?
If it does, try removing it or changing to without sharing. There may be an issue with the user that the post install script is running as not being able to access the custom object when sharing rules are enforced.
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 .
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 ...
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 ...
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 ...
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 ...
Once you have a managed package you will know the Org id of your packaging org (and that's never going to change). In your code you could check the Org Id using UserInfo.getOrganizationId() against the packaging org id (hard-coded)
(1) the namespace will be present, but the org id will not be the same as the packaging org id
(2) the namespace will be ...
No, you can't dynamically create schema with a package. You would need to either include all fields and "feature" them selectively in different configurations or have different packages.
EDIT: Have you considered a package with a base schema, that is needed in all configurations? Then you have a series of other packages which extend your base package and ...
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....
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 ...
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/
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 ...
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. ...
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'm also a consultant. We don't see a need to mess with the Ant tool or any of that nonsense. We utilize MavensMate and Sublime Text 3 along with the sourceTree or the git client of your choice.
MavensMate handles the local <--> sfdc connection and git takes care of the rest. If you're not set on a fancy gui for git you can even do everything inside ...
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 ...
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 ...
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.
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 ...
Typically you don't have to revisit all of your code. Most things will continue to run after the prefix is added.
But most doesn't mean all. I found these points requiring modifications:
Objects accessed via API
as a consequence existing integrations and ETL processes
Metadata accessed via API including use of Metadata Service.cls for APEX
Usage of Ajax ...
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.
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.