-
ChatterFeed
-
0Best Answers
-
0Likes Received
-
0Likes Given
-
5Questions
-
2Replies
Deploying metadata via Eclipse / Force.com IDE - Property 'valueSet' not valid in version 37.0
Trying to deploy metadata objects via Force.com IDE / Eclipse. Getting an aerror that property 'ValueSet' cannot be deployed because its not valid in API 37. How do I sepecify whcih version of the API Eclipse uses for deployments?
-
- Vinny Gebhart 10
- November 01, 2016
- Like
- 0
- Continue reading or reply
objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used. Please choose a different name.
Using Metadata API to update org and running into this error in certain scenarios. II have other list views that also exist previously but those load fine. I found an article about sharing settings however I've tried removing sharing settings, changing to public group but these continue to fail.
objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used. Please choose a different name.
Is there a way to bypass this check?
-Vinny
objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used. Please choose a different name.
Is there a way to bypass this check?
-Vinny
-
- Vinny Gebhart 10
- October 21, 2016
- Like
- 0
- Continue reading or reply
Quesiton about using force CLI and fetch command for unmanaged packages
Hi there,
using force CLI and trying to retrieve an unmanaged package from our dev org. I'm able to use the export command to get all metadata but striking out to limit the pull to our unmanaged package.
Package name = Initial
force fetch -t=package -n=Initial
System Response --> Exported to metadata
Actual result is no metadata is downloaded
using force CLI and trying to retrieve an unmanaged package from our dev org. I'm able to use the export command to get all metadata but striking out to limit the pull to our unmanaged package.
Package name = Initial
force fetch -t=package -n=Initial
System Response --> Exported to metadata
Actual result is no metadata is downloaded
-
- Vinny Gebhart 10
- October 18, 2016
- Like
- 0
- Continue reading or reply
Deploying code designed to be in managed package as unmanaged to a new org
Hi all,
Here's our back story:
We have an app that we developed (with a partner) to be a managed package deployment. It's not meant for app exchange, simply a package we deploy for each of our clients when they come online with our service. The partner who developed the org worked from one sandbox for their development, then bundled components as they were complete and moved to a "packaging" dev org where they created a managed package which we then install on client orgs.
Here's our current challenge:
That original org where the app was developed is no longer sufficient as we're expanding our dev team. Our goal is to pull all of that code to a new fully licensed org so we can spin off developer sandboxes, refresh them as necessary, and streamline our deployment and development processes. The issue is when we use the meta-data API to extract all code from the original org, we're unable to deploy it to a new org due to many dependencies and circular references between classes, objects, etc. It seems Salesforce isn't able to handle "fixing" these dependencies on the fly. We have tried scrubbing the XML package for any dependendent fields, classes, etc. which does limit the number of errors we get but we do still need to deploy all of the code at some point and at this point its incredibly manual and best described as "brute force".
Can anyone recommend a better / stronger practice for deploying a batch of metadata, code, classes, etc. to a new org in a way that will be successful? Please note - the reason we're not deploying this as a managed pkg is so developers can work on the code / classes directly and test in place.
Any help is greatly appreciated.
-Vinny
Here's our back story:
We have an app that we developed (with a partner) to be a managed package deployment. It's not meant for app exchange, simply a package we deploy for each of our clients when they come online with our service. The partner who developed the org worked from one sandbox for their development, then bundled components as they were complete and moved to a "packaging" dev org where they created a managed package which we then install on client orgs.
Here's our current challenge:
That original org where the app was developed is no longer sufficient as we're expanding our dev team. Our goal is to pull all of that code to a new fully licensed org so we can spin off developer sandboxes, refresh them as necessary, and streamline our deployment and development processes. The issue is when we use the meta-data API to extract all code from the original org, we're unable to deploy it to a new org due to many dependencies and circular references between classes, objects, etc. It seems Salesforce isn't able to handle "fixing" these dependencies on the fly. We have tried scrubbing the XML package for any dependendent fields, classes, etc. which does limit the number of errors we get but we do still need to deploy all of the code at some point and at this point its incredibly manual and best described as "brute force".
Can anyone recommend a better / stronger practice for deploying a batch of metadata, code, classes, etc. to a new org in a way that will be successful? Please note - the reason we're not deploying this as a managed pkg is so developers can work on the code / classes directly and test in place.
Any help is greatly appreciated.
-Vinny
-
- Vinny Gebhart 10
- October 12, 2016
- Like
- 0
- Continue reading or reply
Help with a SOQL query between custom object and standard object
Hi all,
Trying to query from a custom object, retrieve the owner (user), and return the related contact field on the user record.
select ID, OwnerID, Name, owner.UserName, owner.IsActive, Owner.ContactID
from CustomObj1
The user type is Customer Community portal user
Trying to query from a custom object, retrieve the owner (user), and return the related contact field on the user record.
select ID, OwnerID, Name, owner.UserName, owner.IsActive, Owner.ContactID
from CustomObj1
The user type is Customer Community portal user
-
- Vinny Gebhart 10
- October 05, 2016
- Like
- 0
- Continue reading or reply
objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used. Please choose a different name.
Using Metadata API to update org and running into this error in certain scenarios. II have other list views that also exist previously but those load fine. I found an article about sharing settings however I've tried removing sharing settings, changing to public group but these continue to fail.
objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used. Please choose a different name.
Is there a way to bypass this check?
-Vinny
objects/Contact.object (Contact.InActive_Contacts) -- Error: This View Unique Name already exists or has been previously used. Please choose a different name.
Is there a way to bypass this check?
-Vinny
- Vinny Gebhart 10
- October 21, 2016
- Like
- 0
- Continue reading or reply
Deploying code designed to be in managed package as unmanaged to a new org
Hi all,
Here's our back story:
We have an app that we developed (with a partner) to be a managed package deployment. It's not meant for app exchange, simply a package we deploy for each of our clients when they come online with our service. The partner who developed the org worked from one sandbox for their development, then bundled components as they were complete and moved to a "packaging" dev org where they created a managed package which we then install on client orgs.
Here's our current challenge:
That original org where the app was developed is no longer sufficient as we're expanding our dev team. Our goal is to pull all of that code to a new fully licensed org so we can spin off developer sandboxes, refresh them as necessary, and streamline our deployment and development processes. The issue is when we use the meta-data API to extract all code from the original org, we're unable to deploy it to a new org due to many dependencies and circular references between classes, objects, etc. It seems Salesforce isn't able to handle "fixing" these dependencies on the fly. We have tried scrubbing the XML package for any dependendent fields, classes, etc. which does limit the number of errors we get but we do still need to deploy all of the code at some point and at this point its incredibly manual and best described as "brute force".
Can anyone recommend a better / stronger practice for deploying a batch of metadata, code, classes, etc. to a new org in a way that will be successful? Please note - the reason we're not deploying this as a managed pkg is so developers can work on the code / classes directly and test in place.
Any help is greatly appreciated.
-Vinny
Here's our back story:
We have an app that we developed (with a partner) to be a managed package deployment. It's not meant for app exchange, simply a package we deploy for each of our clients when they come online with our service. The partner who developed the org worked from one sandbox for their development, then bundled components as they were complete and moved to a "packaging" dev org where they created a managed package which we then install on client orgs.
Here's our current challenge:
That original org where the app was developed is no longer sufficient as we're expanding our dev team. Our goal is to pull all of that code to a new fully licensed org so we can spin off developer sandboxes, refresh them as necessary, and streamline our deployment and development processes. The issue is when we use the meta-data API to extract all code from the original org, we're unable to deploy it to a new org due to many dependencies and circular references between classes, objects, etc. It seems Salesforce isn't able to handle "fixing" these dependencies on the fly. We have tried scrubbing the XML package for any dependendent fields, classes, etc. which does limit the number of errors we get but we do still need to deploy all of the code at some point and at this point its incredibly manual and best described as "brute force".
Can anyone recommend a better / stronger practice for deploying a batch of metadata, code, classes, etc. to a new org in a way that will be successful? Please note - the reason we're not deploying this as a managed pkg is so developers can work on the code / classes directly and test in place.
Any help is greatly appreciated.
-Vinny
- Vinny Gebhart 10
- October 12, 2016
- Like
- 0
- Continue reading or reply