+ Start a Discussion
JonPJonP 

Force.com IDE Summer '08 Developer Preview is now available!

Summer '08 Metadata API Support adds the following Salesforce components:
  • Home Page Components
  • Home Page Layouts
  • Page Layouts
  • Validation Rules
  • Workflows
Project Contents Selection lets you control what to download:
  • All packages and default unpackaged components (identical to previous releases)
  • Single package
  • Selected metadata types only
  • None (if loading project from version control system)

Usability Enhancements
  • 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

Resources
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
TehNrdTehNrd
I haven't had a change to upgrade yet but are the layouts for all objects or just custom objects?


Message Edited by TehNrd on 06-17-2008 12:05 PM
JonPJonP
Yes, page layouts are available for both standard and custom objects.
TehNrdTehNrd
....but still no support for standard sObjects :smileysad:

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.
JonPJonP
TehNrd,

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.

Jon
TehNrdTehNrd
Now that is just awesome! Thanks for that tip as I had no idea that was possible, didn't see it in any docs/release notes.

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
Luigi MontanezLuigi Montanez
JonP,

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:

Code:
<types>
    <members>*</members>
    <name>CustomField</name>
    <members>Opportunity.SomeExistingCustomField__c</members>
</types>

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?

Thanks,
Luigi

JonPJonP
Luigi,

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":

Code:
<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:

Code:
<—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.
Jon

Luigi MontanezLuigi Montanez
Thanks Jon for the quick reply. I'm not sure what it was, but when I tried everything again, it worked exactly as it should have.
TehNrdTehNrd
There appears to be a bug with the layouts pulling the ID of fields rather than the API name.

http://community.salesforce.com/sforce/board/message?board.id=apex&message.id=6142