Help us improve Gearset
We love getting feedback from our users on how we can make Gearset even better. Post your ideas for improvements, new features, and bug fixes alike, and vote for others – let us know what’s important to you.
82 results found
-
Warn if source version is greater than the version of the target org.
Often, salesforce will deploy the latest API version to sandbox orgs before production orgs. Therefore it's easy to use API version 55 in your sandbox and then get a failure message when you try to deploy it to your production org which is at version 54. Unfortunately, you have to start to validate your deploy before you get this message. This could be a pre-deployment issue that you can notified right away.
1 vote -
Provide help link/button on each analyzer problem pane with specifiec discussion
Suggestion
In "Problem Analysis" page, the problems indicated and solutions are not necessarily obvious and understandable.The suggestion to read more about the analysers in the user guide is in the case I'm facing an enormous challenge.
Copy and paste the problem into your search mechanism brings back endless answers - not one used the wording in the problem statement!.
Here's an idea, have a button/link with each problem that take one to the user guide section (or other documentation) exploring the problem.
No hunting for answers as the 1st choice to figure out what your product is saying. It's…
1 vote -
Apply certain PA outputs back to the comparison as a "quick fix"
The main example where I have wished for this pretty strongly is the "missing permissions" PA. This is the one that warns "not all permissions are included in the deployment". It would be useful to be able to go from that PA to a view where one could either add all the missing permissions in one go, or do so selectively by profile or permission set. Right now one has to screen scrape the output, paste it into a text file, go back into the comparison and laboriously hunt through the comparison to find the missing nodes, then add them.
1 vote -
Provide output from Gearset during the validation in terms of what tests were being run
I had unit testing jobs running ALL tests in source (full sandbox) and target (production) org - resulting in 80% and 79% test coverage. However, when I started to deploy my changes - the validation failed because test coverage was only 74%. Finally, after a few days, I figured it out.
I was just simply clicking "Validate" (i.e., did not choose specific tests). In the past - that ran "all tests". But something seems to have changed. When I picked "choose tests", about half the tests in my org were "automatically selected". I manually selected all other tests - effectively…
1 vote -
Move Failed Tests before Passed Tests when deployment Fails
Hi,
I would love to see the Failed tests to be listed above the Passed tests in case deployment fails.
Right now User has to always scroll down at the list (as you are usually not interested on what has Passed rather what Failed).
Also this shouold be super simple to implement :)
Thank you & keep up the good work,
Cheers,
O.1 vote -
Improve error message when XML is not properly escaped
When I choose to compare metadata with my source as my VCS, there was an "&" char in the recordtype XML definition file.
<values> <fullName>Food & Beverage</fullName> <default>false</default> </values>This threw an error and there was no support and no explanation at that time.
I suggest you to improve this error message.
Message I got:Could not parse the XML for 'force-app/main/default/objects/Lead/businessProcesses/Buyer.recordType-meta.xml'. Error occurred at line 71. Further details: An error occurred while parsing EntityName. Line 71, position 29.
File, line and position it's ok. maybe a link to Gearset docs with walkthrough with this probable cause when a parsing…
1 vote -
1 vote
-
Don't Delete Managed Package's object permissions from Permission Sets in CI jobs
In a CI job, using source control as the source and including deleted items, you can run into an issue where objects from managed packages show as "deleted" in terms of custom object permissions from permission sets that have access to them. This can occur for permission sets designed to give access to managed package features or if you have a permission set with "View all data" or a system permission that gives them access to all objects in some capacity (read, write).
Ideally, we wouldn't have to include managed package object permissions into Source Control (likewise, Gearset suggests only…
1 vote -
Workflow failed to deploy without error, due to standard object dependency
In a CI job : Validation shown as success & Deployment shown as success. But actually no workflow deployed due to it being removed in the Problem Analyser.
The Problem Analyser triggered due to the (standard) object, that the workflow depends on, not being in the comparison results.
In a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap - problem analysers should never fire on object dependency.
1 vote -
Workflow failed to deploy without error, due to standard object dependency
CI job : Validation shown as success & Deployment shown as success.. but actually no WF deployed. Saying Opportunity object doesn't exist in target just because it was not selected in the components. in a traditional deployments object is not needed to deploy WF, that too standard object. I feel it is a gap.
1 vote -
Excluding Record Type Problem Analyzer Should Behave the Same Across Metadata (Layout Permissions, Custom Object Permissions)
In the situation where a repository is the source and an org is the target, there may be a situation where a record type doesn't exist in the repository but references in the layout permissions and custom object permissions do still exist.
Currently, the problem analyzer will catch the custom object permissions and ask you to remove the references to the record type that doesn't exist in the target.
However, it doesn't catch the layout permissions and the deployment could fail with an invalid reference.
In the absence of the record type in the repository, the "Problem Analyzer for excluding…
1 vote -
Warning On Missing Custom Metadata Field
I had a deployment fail today due to a difference between a custom metadata type's definition in the source org vs the destination. The source had two extra fields that the destination did not have. This cause the metadata record deployment to fail, because two extra values were included in the deployment which did not have corresponding fields in the destination. Because the fields were for a custom metadata package, I was unable to (easily) add the fields into the destination org.
I'd like to see a way to suppress custom metadata values. This may be solvable through the inline…
1 vote -
Possibility to add automatically added metadata to the comparison after a failed deployment
The dependency crawler that GearSet offers is one of its biggest strengths. A lot of manual labor can vanish at the click of the button. Best example would be the addition of all relevant Picklist fields when a Record Type is added to the Selected Items.
Sometimes deployments still fail, and in particularly big orgs the dependency crawl takes ages, each time I have to rerun the problem analysis.
A way to add the metadata that was auto-added prior to the deployment to the list of Selected Items to make future analysis faster would be greatly appreciated.
1 vote -
Improve the UI around deployment objects dependent on objects not in the comparison
Deployment of certain types of objects requires that other objects on which they are dependent be included in the deployment. If the needed objects have not been included in the selected items and they are not part of the comparison, Gearset will display the following message:
Problem: Some itmes reference componnents that were not downloaded from either the source or the target.
Solution: Removing the elements that reference missing components from the affected items will make the deployment more likely to succeed.
Below this is displayed a table with a column of checkboxes at the left and three additional columns:…
1 vote -
Display "No Difference" metadata sources on Deployment Summary page
On the "Deployment Summary Page" it would be great to add a column to the list of metadata components added which shows for the "No Difference" items showing the source piece(s) of metadata which is causing this "No Difference" to be included.
This would dramatically help in the narrowing down of why a piece of metadata is included - especially if that piece of "No Difference" is a managed package and cannot be altered. In a large deployment, trying to identify a root cause for why a component was added is quite difficult. Simply giving a way to track back…
1 vote -
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 - invalid1 vote -
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 -
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 voteHi!
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.
-
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 subcomponentsSince 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…
1 vote -
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…
1 vote
- Don't see your idea?