87 results found

1. Improve error handling for invalid XML metadata files

   Currently, when there is an error with an XML metadata file (usually introduced by git merges), Gearset will produce an error, either in the Initializing Comparison, or Checking Deployment stages, stating simply that "An unknown error occurred."

   If Gearset instead ran the XML from source control through an XML validator using the Partner WSDL XMLSchema, then we could get file-level validation errors if the XML doesn't conform to what Salesforce's Metadata API will accept.

   e.g.:
   $ xmlstarlet val -e -s ~/Downloads/salesforce-schema.xml force-app/main/default/profiles/Marketing.profile-meta.xml
   force-app/main/default/profiles/Marketing.profile-meta.xml:17108.15: Element '{http://soap.sforce.com/2006/04/metadata}field': This element is not expected.
   force-app/main/default/profiles/Marketing.profile-meta.xml - invalid

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Problem analysis and deployment failures  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Better handle Shares on Report and Dashboard Folders in pre-validation

   during the pre-validation of a deployment, validate that the shares exist for report and dashboard folders. Currently if they do not exist in the target they fail during deployment. Only option today is to clean them up after error in source org and then redeploy. Instead, it would be useful if gearset removed them during the pre-validation.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Problem analysis and deployment failures  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Better Targeted Static Code Analysis Feedback Surpression

   Currently, if I want to suppress errors from static analysis, the suppression seems to be all-or-none at the class level.

   I would prefer to suppress only the specific errors when they happen.
   (e.g. in the method or in the line.)

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   AdminGearset Team (Feedback Manager, Gearset) responded

   Hi!

   Our static code analysis is built on PMD. Currently, the only error suppression that works with Apex code in PMD is the `@SuppressWarnings` annotation. (This was introduced for Apex in PMD version 6.0.0). As you say, you can suppress all rules, or specific rules, at the class level, but can’t make more fine grained suppressions, unfortunately.

   There are other methods of suppressing errors within PMD for other languages, but these don’t currently work with Apex. We’ll keep an eye on future versions of PMD to see if they introduce new methods of suppressing warnings for Apex code.

4. Avoid Analyzer suggesting to deploy a workflow's Sobject when such SObject and all referenced fields exists in the target

   Use case:
   1. Deploy from source to target a changed Workflow (from active to deactivated)
   2. Target already has all of the workflow's referenced components (fields used in filter criteria, fields used in Field Update)

   Analyzer will tell you "Add the following to the deployment" and something that looks like:

   Deploy All
   - object.WfName
   -- object and its subcomponents
   -- object and its subcomponents
   -- object and its subcomponents

   Since the object is already in the target as are the subcomponents, this message is alarmingly misleading and could inadvertently lead to deploying an object not yet ready.

   The above message should appear ONLY if the workflow references components that are not in target nor are in the deployment package

   Use case:
   1. Deploy from source to target a changed Workflow (from active to deactivated)
   2. Target already has all of the workflow's referenced components (fields used in filter criteria, fields used in Field Update)

   Analyzer will tell you "Add the following to the deployment" and something that looks like:

   Deploy All
   - object.WfName
   -- object and its subcomponents
   -- object and its subcomponents
   -- object and its subcomponents

   Since the object is already in the target as are the subcomponents, this message is alarmingly misleading and could inadvertently lead to deploying an object not yet ready.

   The above message… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Error while deploying dashboard component using Changeset / Gearset / ANT

   This is a common error received during deployments:

   Error: Metric, gauge, or table dashboard component missing indicatorLowColor attribute (line 70, column 33)

   This is a suggestion to Gearset team for there feature Deployment analysis if they would pick this error in advance before deployment.

   Observation: This issue occurs when the Dashboard is created in Lightning. (I cannot confirm though)

   Resolution:

   Downloaded package.xml and component

   Basically, after I pulled the dashboard metadata from source org, I opened it and found the
   <componentType>Table</componentType> tag, and right under it I added this:

   <indicatorHighColor>#00716B</indicatorHighColor>
   <indicatorMiddleColor>#ffb75d</indicatorMiddleColor>
   <indicatorLowColor>#C23934</indicatorLowColor>

   After this change I managed to deploy everything to my destination org, and everything seems to be working fine.

   Hope this helps.

   Thanks.

   This is a common error received during deployments:

   Error: Metric, gauge, or table dashboard component missing indicatorLowColor attribute (line 70, column 33)

   This is a suggestion to Gearset team for there feature Deployment analysis if they would pick this error in advance before deployment.

   Observation: This issue occurs when the Dashboard is created in Lightning. (I cannot confirm though)

   Resolution:

   Downloaded package.xml and component

   Basically, after I pulled the dashboard metadata from source org, I opened it and found the
   <componentType>Table</componentType> tag, and right under it I added this:

   <indicatorHighColor>#00716B</indicatorHighColor>
   <indicatorMiddleColor>#ffb75d</indicatorMiddleColor>
   <indicatorLowColor>#C23934</indicatorLowColor>

   After this change I managed to deploy everything… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

6. Field Tracking Analyzer message is misleading

   If source org includes a new custom field with field history tracking enabled TRUE, the deployment analyzer reports the following when deploying to target org:

   'Fields with history tracking enabled cannot be deployed before it is enabled on the object. You should remove these history tracking changes from the deployment'

   Specific use case was object OrderItem

   1. Analyzer can clearly detect if field history is enabled on target org object (which it was) - message is spurious.

   2. Analyzer can arguably detect that target org's limit (20) will be exceeded by the deployment of the selected custom fields (which could add/remove field tracking from 1+ fields). In my use case, this was in fact the case so if analyzer is detecting this, the message should be reworded

   As an aside, what happens if org has purchased Field Audit Trail (where the 20 limit is not applicable).

   If source org includes a new custom field with field history tracking enabled TRUE, the deployment analyzer reports the following when deploying to target org:

   'Fields with history tracking enabled cannot be deployed before it is enabled on the object. You should remove these history tracking changes from the deployment'

   Specific use case was object OrderItem

   1. Analyzer can clearly detect if field history is enabled on target org object (which it was) - message is spurious.

   2. Analyzer can arguably detect that target org's limit (20) will be exceeded by the deployment of the selected custom fields (which could add/remove field… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Clarify installation of managed packages and allow opt-out

   It appears that if there are dependencies in the deployment that require a Managed Package to be installed/updated, that package is automatically installed/updated before the deployment takes place.

   This is great, but it needs more clarity and control for the user.

   It would be nice to know if Managed Packages are going to be installed as the result of a deployment, and if so, opt-in or opt-out of that process. It would be great if opting-out also displayed the related metadata with the dependency so those could be excluded as well.

   This may also avert some errors where metadata needs a Managed Package already installed in order to be deployed successfully.

   It appears that if there are dependencies in the deployment that require a Managed Package to be installed/updated, that package is automatically installed/updated before the deployment takes place.

   This is great, but it needs more clarity and control for the user.

   It would be nice to know if Managed Packages are going to be installed as the result of a deployment, and if so, opt-in or opt-out of that process. It would be great if opting-out also displayed the related metadata with the dependency so those could be excluded as well.

   This may also avert some errors where metadata needs… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Problem analysis and deployment failures  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating