- General Development
- Schema Development
- Apex Code Development
- Visualforce Development
- Formulas & Validation Rules
- Force.com Sites & Site.com
- Chatter Development
- Java Development
- .NET Development
- Perl, PHP, Python & Ruby
- Desktop Integration
- APIs and Integrations
- Visual Workflow
- Apple, Mac and OS X
- VB and Office Development
- AppExchange Directory & Packaging
- Salesforce Labs & Open Source Projects
- Other Salesforce Applications
- Jobs Board
06-16-2008 05:44 PM - edited 06-19-2008 02:05 PM
- Home Page Components
- Home Page Layouts
- Page Layouts
- Validation Rules
- All packages and default unpackaged components (identical to previous releases)
- Single package
- Selected metadata types only
- None (if loading project from version control system)
- Simplified connection options in the New Force.com Project wizard
- Refresh objects list from within the New Apex Trigger and New Workflow wizards
- Force.com Projects now use Eclipse proxy server settings, rather than per-project settings
- Improved stability and performance
Visit the IDE Home Page on developer.force.com, or jump straight to the information you want:
Message Edited by JonP on 06-19-2008 02:05 PM
06-16-2008 10:32 PM - edited 06-17-2008 12:05 PM
06-19-2008 04:07 PM
I long for the day when I can create new fields and page layouts in a sandbox then move them to production with one push. It does look like I can do this for custom objects, so that is cool. Page layouts will definitely save time as no one likes rebuilding those things in production but if there are new fields for a standard sObject it appears you must first create these in the UI and then push the layout.
Everything else looks good. I especially like the process when building project you can now select exactly what components you want to pull down. Static resources is also plus as previously this required uploading through the UI before deployment.
06-19-2008 04:36 PM
Custom fields on standard objects have been available in the IDE as long as custom objects have been--at least since Winter '08. They merely are not included by default by the Metadata API.
To include custom fields on standard objects in your IDE project (or with the Ant tool), edit src/unpackaged/package.xml, find the <types> section for CustomObject, and add a <members> tag containing the standard object name, e.g. "<members>Account</members>". The next time you refresh from the server, you will get (for example) an Account.object file containing all the unpackaged custom fields on Account, and your Profile records will include permission settings for all custom AND STANDARD fields. Or you can specify individual custom fields by adding a <types> section containing "<name>CustomField</name>" and a <members> tag for each field, e.g. "<members>Account.MyCustomField__c</members>", which will alsocause just those named custom fields to be included in Profiles.
The reason why we do not include standard objects by default is that an uninformed user could very easily mistakenly overwrite field level security on standard fields by deploying a profile with standard field FLS to his or her production environment. We are exploring UI models in the IDE to balance ease of use with proper user notification of this risk, but for the Force.com IDE Summer '08 Developer Preview release we've continued to leave this behavior obscure.
06-19-2008 04:57 PM - edited 06-19-2008 04:59 PM
I see that for profiles it is only pulling down standard profiles. Can this XML file be modified to pull down custom profiles as well?
So you are concerned someone will overwrite FLS for standard objects but not for custom objects?
Message Edited by TehNrd on 06-19-2008 04:59 PM
06-26-2008 04:11 PM
Thanks so much for the tip on Custom Fields in Standard Objects. I've blogged about it here:
Salesforce on Rails
However, when I tried the CustomField solution:
<types> <members>*</members> <name>CustomField</name> <members>Opportunity.SomeExistingCustomField__c</m
When I refreshed, I got back all the fields from the Account object, not just the single one I specified. I purposefully did not put the Opportunity object in the CustomObject subtree, and I tried the CustomField subtree with and without the <members>*</members> as the first line.
Is there something I'm missing?
Blog: Salesforce on Rails
06-26-2008 04:33 PM
Great blog post--thanks for helping get the word out! I'm adding you to my blog reader. Now on to CustomField...
The following works perfectly for me in "src/unpackaged/package.xml":
<types> <members>Opportunity.OrderNumber__c</members> <name>CustomField</name> </types>
Once I make this change, I right-click on "src/unpackaged/" and select Force.com > Refresh from Server, and the file "src/unpackaged/objects/Opportunity.object" appears in my project:
<—xml version="1.0" encoding="UTF-8"–> <CustomObject xmlns="http://soap.sforce.com/2006/04/metadata"> <fields> <fullName>OrderNumber__c</fullName> <label>Order Number</label> <length>8</length> <type>Text</type> </fields> </CustomObject>
Note that I have 5 custom fields on Opportunity in my organization, so it's correctly returning only the one I requested. If I'd asked for others, they would all appear in the same file.
Have you created any packages in your organization? The "src/unpackaged/" folder always excludes metadata components that are included in any package. Another useful troubleshooting technique is to try your package.xml file with the Force.com Migration Tool (for Apache Ant) and see if the results are the same--they should be.
A few other very minor points, as an FYI:
- The CustomField type does not support wildcards. If you try to use the wildcard, it will be ignored and you should receive the warning message in Eclipse's problem view, "Refresh error: Entity type 'CustomField' does not support wildcard."
- Technically all instances of the <members> tag should come before the <name> tag, but the server is forgiving. It will work fine either way, but you may have noticed that after refreshing, your package.xml file is changed and the XML elements ordered correctly.
06-26-2008 05:17 PM
Blog: Salesforce on Rails
07-03-2008 02:17 PM