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.
214 results found
-
Increase the size of the 'Create new branch from...' modal.
When creating a new branch from the 'Create new branch from...' model, it's hard because of the small size of the modal/dialog. Just sizing the modal/dialog larger would make it easier to work with.
1 vote -
Field Dependencies for Reports
When deprecating a field and replacing it with a new one, we need to be able to see where they are used in all reports, including private folders, which the "Where is this used?" feature does not detail.
1 vote -
Add the ability to run the problem analyzer while on the comparison screen
I originally was going to request the ability to append the items found in problem analyzer to the list of selected components, when going back to view the comparison, but then I thought why not take it one step further, and move the problem analyzer feature to the comparison screen? Then, the items it finds/suggests, the user can add them to the package there, or choose to ignore them.
3 votes -
add the option to either hide source control locations where you do not have a connection, or allow a default SCM connection to be selected.
We only use on source control service, so having to select 'Azure DevOps' before being able to select the repo/branch, is a small step that adds up over time.
Being able to either hide services that you do not already have a connection for, or being able to default to a service, with the ability yo navigate back up and over, as needed. would be welcomed.
3 votes -
Add Comparison Column for "Environment"
Add a column for "Environment" which signifies which environment the change took place. For instance, this would tell you whether the changes took place in Production Only, Sandbox Only, or both.
Then, I could filter by Sandbox Only and both to see only the changes I made recently in the sandbox that I need to push to Production. Right now, I have to sift through the many little changes to items that occurred in Production.
1 vote -
Filter Column Sub-Levels
If I filter a column, it does not apply those filters if I open the sub-levels of an item such as "Depends on" or "Used by". For instance, if I filter OUT under the "Difference Type" column "No Difference," when I search through those sub-levels, it should not show me items that are "No difference."
1 vote -
Add an Undo Action/Functionality in the Comparison UI
Add an Undo button to the comparison UI in case someone accidentally de-selects a component from the Selected Items tab. It would save time rather than having re-search for the component and lose your train of thought. You have this feature in Google Docs and sheets.
2 votes -
sfdx repo deployment should be in subcomponents
Context: Compare and Deploy from Org to a Repo.
as i understand it, even if my repo is in SFDX format (Object subcomponents), Gearset still does the compare in the metadata format.
it reads the components from sfdx, combines into a .object form, and then applies the changes to the .object file and then decomposes again.this is causing unintentional changes to be part of our PR
2 votes -
Offer option to auto-limit items in clone comparison
When a deployment is completed, you have an option to clone that package. For many of my deployments, I want to push a package to source control, and then on to production. The second comparison could be limited to just the items in the cloned package. Would be great to have an option to limit second comparison to only the meta-data items in the clone. Would allow subsequent comparisons to run much more quickly, if the user is confident that the package has everything needed for that specific deployment.
1 vote -
Option to ignore package namespaces differences in Apex classes
Our Apex Classes reference multiple managed packages that are updated automatically in our sandbox/production environments. This causes many classes to get picked up unnecessarily in our comparisons/CI deployments between source control (where the managed packages are not committed) and org.
Unlike https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/43917792-add-an-option-to-ignore-package-version-difference this is specifically for different package namespaces between the source and target.
In this example the source has one namespace and the target has 2 package namespaces.
It would be very useful to be able to choose to ignore all package differences in comparisons and CI jobs as a team-wide setting.
1 vote -
Create new branch using type-forward / auto-complete from JIRA (or other supported tool)
It would be great if you have JIRA connected, to make it easier to create your branch. So basically type-forward (-ish) functionality to identify a JIRA ticket and take the issue ID and description as branch name.
Say your JIRA ticket is ISSUE-1234 Implement this awesome feature.
The default branch name would be issue-1234-implement-this-awesome-feature.
(Where it reads JIRA could be Azure or any other support tool of course).
1 vote -
Prevent Accidental Backing Out of Deployment components when Deploying Multiple Packages
Sometimes I have multiple packages that have been validated, that I am looking to deploy. If they happen to overlap components, then deploying in the wrong order could back out a change made by the earlier deployment.
From this I came up with two ideas that could help:1) The ability to select multiple validated packages or draft deployments, and click a button that will tell me if they have overlapping components. That will let me know if I have anything to worry about; if they overlap then maybe I should combine them into one package.
2) The ability to…
1 vote -
The ability to deploy only certain fields in a record type and not all fields
If we want to promote a change to a single field in a record type, we're unable to because the file is pushed in it's entirety. We'd like the ability to view from list of available changes in a record type by field and select just the changes to the fields we want to promote.
3 votes -
Rename the Name bar in compare and deploy to : Name (api)
Simple to implement, just a string rename...
Rename the Name bar in compare and deploy to : Name (api)
It would show clearly that the name displayed there is the API name, not the "label" name XD
Cheerio2 votes -
Enhance Metadata Filter Type Recognition
Our team has struggled learning the Metadata API names of metadata types when compared to what items are called in change sets. One example would be to highlight Weblink when a user searches for Button.
2 votes -
Option to ignore: <personAccountDefault> in XML
When comparing XML for RecordType permissions in Profiles, some Sandboxes return:
<personAccountDefault>true</personAccountDefault>As part of the XML, even though person accounts are not enabled, this makes comparing annoying.
It would be nice to have an option to ignore this.
8 votes -
Ignore "trackHistory" comparison if an Org has "FALSE" and Git does not define this entry
The Salesforce CLI system returns the Custom Field Metadata XML file without a "trackHistory" entry if it is set to false. This XML entry is optional in the Custom Field metadata type. However, once we deploy such metadata to the org and execute compare between a branch and the org again, it shows differences, saying that "trackHistory == false". But is "false" by default. So I would recommend you ignore this entry if SF Org returns FALSE and the VCS file does not have this item.
1 vote -
Pop Out Diff File in Comparisons
The current UI design for comparisons is very unfriendly to smaller screens. When working on a laptop viewing the comparison and the Diff files together is nearly impossible. It would be useful to be able to pop out a diff file or open it in another tab so it can be better viewed.
1 vote -
Make org-org and org-VCS compare differences work the same
There is no end to confusion on the part of the devops user when Gearset displays differences "differently" when comparison is org-org vs. org-VCS
Gearset should apply a consistent principle - to see a Profile subcomponent, the compare filter should include both sides of the subcomponent (e.g. Profile + ApexClass to see ApexClassPermissions; Profile + Layout to see layoutAssignments; etc.)
If both sides of the subcomponent are not included in the filter, then there's no difference to show.
Note that these use cases must also be supported:
Profile deleted in org; org->VCS compare should delete .profile file…
2 votes -
r.uzdavines@nextech.com
It would be great if I could group my Selected Items into groups or Projects, so that I could filter and just see those. Now that I've added a bunch of items for different projects, it's a little hard to quickly decipher which project it applies to. I'd like to be able to double check each Project's list right before deploying to make sure I've added everything. Maybe you can add another column and allow the user to create new values for "Projects."
1 vote
- Don't see your idea?