You need to sign in to do that
Don't have an account?
cgoss
Metadata API and Installed Package Bug
I am working on a tool that will automatically update some page layouts. Some of the layouts are on standard objects and others are installed from a managed package. I can make the changes just fine and re-deploy for the standard layouts, however, I'm seeing something very strange when trying to update managed object layouts. Here's what I'm doing (from Java, if that makes any difference).
1. Retrieve the managed package meta-data by name (in files)
2. Retrieve the unpackaged page layouts only (also in files)
3. Parse through the layouts, making changes to the ones I need to (adding fields, moving fields, etc)
4. Copy the changed files to a new directory to be zipped and deployed
5. Create a new package.xml with just the changed items listed
6. Deploy the changed set
The only way I could get SF to accept the change to the packaged layout is by adding the package namespace to all the components:
1. Layout file name goes from "CustObject__c-Custom Layout.layout" to "ns__CustObject__c-cv__Custom Layout.layout"
2. Prepend each custom field and button name in the layout with namespace
3. Update package.xml to reflect new member name (same as above, without the .layout suffix)
When all this is done and the changeset is deployed, the layout is in fact updated with the changes. HOWEVER, the name of the layout (which is not editable through the UI) is changed to have the namespace prefix. See screenshot below...
This seems like a major bug. I'm sure this would cause a problem when upgrading the package, and it also violates SF's restriction on double underscores in the name of anything.
Anyone have any ideas on how to correctly deploy changes to managed-installed layouts?
Message Edited by cgoss on 01-15-2009 11:19 AM
1. Retrieve the managed package meta-data by name (in files)
2. Retrieve the unpackaged page layouts only (also in files)
3. Parse through the layouts, making changes to the ones I need to (adding fields, moving fields, etc)
4. Copy the changed files to a new directory to be zipped and deployed
5. Create a new package.xml with just the changed items listed
6. Deploy the changed set
The only way I could get SF to accept the change to the packaged layout is by adding the package namespace to all the components:
1. Layout file name goes from "CustObject__c-Custom Layout.layout" to "ns__CustObject__c-cv__Custom Layout.layout"
2. Prepend each custom field and button name in the layout with namespace
3. Update package.xml to reflect new member name (same as above, without the .layout suffix)
When all this is done and the changeset is deployed, the layout is in fact updated with the changes. HOWEVER, the name of the layout (which is not editable through the UI) is changed to have the namespace prefix. See screenshot below...
This seems like a major bug. I'm sure this would cause a problem when upgrading the package, and it also violates SF's restriction on double underscores in the name of anything.
Anyone have any ideas on how to correctly deploy changes to managed-installed layouts?
Message Edited by cgoss on 01-15-2009 11:19 AM
The namespace-prefixed names in deploy (and retrieve) are there when not in the context of a package (where they are omitted) -- this is consistent with what you described. Feel free to contact me if you have some questions around this or how your tool should deal with packages.
The layout name change <is> a bug and will be fixed shortly in an upcoming release.
Thanks,
- Bill
Can you please provide the sample code for creating pagelayouts and mapping fields to it from Java.
I am able to view required fields in the standard page layout. But not required fields are not visible
Thanks in advance
The required/readonly/editable state of a field is set in the 'behavior' tag. It's values are Edit, Readonly, or Required.
Ah, I misstated the behavior property for editable (should be "Edit" )- here's the XML of a field element that I'm inserting.
<layoutItems>
<behavior>Edit</behavior>
<field>ns__Description__c</field>
</layoutItems>