function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Cory CowgillCory Cowgill 

Unmanaged Package - Installation Error - Overlapping Custom Objects/Fields

This is just a general question.

 

I have a SF Org where some admins have already built out a bunch of custom objects, fields, etc (Just configuration, no code).

 

These folks now want to package up the base objects to create a 'Template' for doing custom installs into different orgs. As we all know, this is a common use case.

 

My problem? Well, they went down the path of creating all this configuraiton out without taking into account the issue of installing a package into an Org with existing Objects and Fields of the same name.

 

Are there any ways to resolve this issue without going into the configuration and changing every single object/field name to XXX_ObjectName? Just looking to see if there are any creative ways to get around this? I doubt it can be done, but thought I'd just throw this out there before I tell them to spend time renaming all their stuff.

 

 

Best Answer chosen by Admin (Salesforce Developers) 
Chris JohnChris John

In which case, have you looked into deploying the components using the force.com IDE?

 

Tasks such as renaming a large amount of objects would be simpler through the metadata API rather than the UI. It would be a matter of creating the force.com project from the dev org and editing the xml files. You can then deploy it to any other org you need the components in or alternatively create the unmanaged package from the original developer org to install in other orgs.

 

Force.com IDE: http://wiki.developerforce.com/index.php/Force.com_IDE

 

HTH,

 

Chris

 

 

All Answers

Cory CowgillCory Cowgill

I should mention that I'm open to non-packaged solutions as well.

 

For example, something leveraging the Migration Tool or IDE to move these objects into different orgs. (I know this breaks some of the benefits of packaging like not needing login information for distribution, but we'll always have login access to the orgs).
Chris JohnChris John

Hi Cory,

 

Is there a reason the package needs to be unmanaged? Did you look into creating a managed package for your base? Managed packages require that a namespace associated with them, so that no name conflicts occur.

 

For reference:

Unmanaged vs Managed packages:http://wiki.developerforce.com/index.php/How_to_Create_and_Register_a_Package#Unmanaged_vs._Managed

 

How to create a Managed Package: http://wiki.developerforce.com/index.php/How_to_Create_and_Register_a_Package#Creating_a_Managed_Package

 

HTH

 

Chris
Cory CowgillCory Cowgill

Thanks for the reply.

 

Yes, it needs to be unamanged so that the source code is available in the new Org and can be modified. Its more of a template and not an application, a starting point for our teams to work off of.
Chris JohnChris John

In which case, have you looked into deploying the components using the force.com IDE?

 

Tasks such as renaming a large amount of objects would be simpler through the metadata API rather than the UI. It would be a matter of creating the force.com project from the dev org and editing the xml files. You can then deploy it to any other org you need the components in or alternatively create the unmanaged package from the original developer org to install in other orgs.

 

Force.com IDE: http://wiki.developerforce.com/index.php/Force.com_IDE

 

HTH,

 

Chris

 

 

This was selected as the best answer
Cory CowgillCory Cowgill

Thanks again dude.

 

I'd spent some time thinking about doing that also, which as you said is easier to do than renaming things in the UI.

 

I mostly wanted to see what other folks ideas were and make sure that I didn't miss something in my initial analysis.

 

:)