I'm a product manager at salesforce.com responsible for Permission Sets. I was able to reproduce this use case. We do intentionally block the setting of parent permissions if it's a standard object (Kibitzer is totally correct with this). I'm working through this use case with my team since this use case is directly related to a custom object from the base ...
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.
Salesforce.com officially accepted this as a bug which can be tracked on their new Known Issues Site:
A workaround is also described there.
You have to clone the SDK from github, not just download. So:
git clone git://github.com/forcedotcom/SalesforceMobileSDK-Android.git
Not simply downloading the zip. This creates a local git repo that the install script requires to use for downloading related projects.
There is a method available in the Test class, that gives you the ability to test InstallHandlers.
You create an instance of your InstallHandler class, and pass it to the `.testInstall()' method, like so.
private class InstallLogicTest
static testMethod void installTest()
InstallLogic postinstall = new InstallLogic();
Uncheck 'Show only the latest versions of available software' and install version 30 of the plugin.
adnsandbox.com is mentioned in the help documentation but I would much rather use the standard installation source.
You may need to uninstall version 31 by going to Help > About > Installation Details.
Once your org has been updated to version 31 you can ...
Since it seems to be an internal Salesforce bug there isn't much you can do about it until they resolve it.
They are onto it:
Team is looking into it right now. W-5394323 for reference if you have a support case or talk to a support agent.
- Farhan Tahir
Circumstantial evidence suggests Summer'17 Patch 19.0 could be responsible. So if you can avoid ...
A managed package will have a namespace and thus should never conflict with subscriber orgs.
With that said I believe you are using an unmanaged package as that is the only way that error would appear....
When you do make it managed, keep in mind the subscriber org will have to migrate all use of their original field to your managed package field.
I don't have an easy way to determine this immediately, but it may be due to the default upgrade type of Mixed. Try using the Delete mode instead:
sfdx force:package:install -p the_package_to_install -t Delete -u myAlias -w 10
You Eclipse IDE has been upgraded to version 31 and the organisation to which you trying to create force.com project support version 30 only. So it is an expected issue. You have to either wait for upgrading organization or downgrade the eclipse plugin to v30.0
Uninstall current plugin and install old plugin from http://www.adnsandbox.com/tools/ide/install/
You can't get Apex Code "for free." Either they upgrade, or you release your app on the AppExchange.
Apex Code isn't "free"; it requires Enterprise Edition or higher. The lower versions are basically teaser versions, with the intent that you'll grow into a larger edition (Enterprise Edition or better). Professional Edition expressly forbids ...
Yes this is posssible using post install scripts. You can implement InstallHandler interface to specify the apex code that runs automatically after the package is installed. In the post install script you can create the custom setting record.
InstallHandler interface documentation link
Not per se. The ways you could achieve something like this are:
use the options in package upload to indicate which features customers must have installed, so they can get warned if they don't have those. This is obviously only usable for the features included in that list, and I am not sure that console is one of those.
have a "mini-package" that customers ...
Mark Pond is correct that you need to be running java 6 but you do not need to remove java 7 from your machine. Just download the java 6 JRE and add a line to the ini file to manually set your java VM. This way it won't get messed up again if you ever switch java versions on your machine.
Instructions on how to add -vm argument are here.
Not to hijack this post but a similar situation occurs when you define a permission set in your extension package where you assign object field permissions for sobject fields that originate in the base package.
After installation of the extension package in an org all your object field settings in the permission set are not copied. The only way around this ...
As requested by @MarkPond.
I am running Java 7 without any issues. My configuration is as follows:
Windows 7 64bit
jdk 7u11 64bit
force.com IDE 64bit (not eclipse + plugin)
I have not made any changes to the forceide.ini
The only thing I can offer is that I don't have java installed in Program Files, it's installed to C:\Java\jdk1.7.0_11 I have no idea ...
You have to use the "antlib:com.salesforce" namespace. Since you defined the namespace as "sf" (xmlns:sf means "define an XML namespace called "sf" with a location of "antlib:com.salesforce"), your "tasks" are defined in this namespace:
<sf:installPackage ... />
Alternatively, you need to make sure you start exactly as specified in the blog that you ...
I have managed to solve it. An email template with the exact same name has been created in the Sandbox in unfiled public, but wasn't part of the unlocked package. After deleting it, I could install the package.
Well, in a nutshell, as some people stated in the comments, the order of execution of the triggers is not guaranteed. Therefor, it's just as if you create two lead triggers in your org and then make a DML - Both will execute, but you will never know which first in advance.
You can find information regarding the order of execution in the docs, here.
You'll have to use Dynamic Apex and/or Dynamic Visualforce in order for you to avoid breaking your compilation and to avoid getting conflicts.
In Apex Code, that looks something like this:
SObjectField someField = Schema.getGlobalDescribe().get(objectName).getDescribe().fields.getMap().get(fieldName);
// You can now reference get/put methods
// Use ...
This error occurs when the Eclipse package was not unzipped properly. There are issues with the Windows built in decompression settings that can cause the folders/files within the package from properly decompressing. To fix delete the Eclipse package that had been decompressed and use a program such as 7-zip to decompress the existing zip file.
I was also faced the same problem and i got the solutions by doing following editing on forceide.ini