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.
1379 results found
-
to add an option to not to run unit tests validation in CI job in case there are no changes detected
2 votes -
Account owner should be able to delete templates created by others
If a team member is removed from Gearset team, any template or previous activity can not be removed by anyone else. Leaving some clutter behind. It would be good to have the Owner of the Gearset account/team to have a super admin level access to all templates/data created by other team members so clean up could be managed....
2 votes -
Support multiple SFDX projects for a custom GIT repo
When comparing / deploying using a custom git repository, containing multiple SFDX projects, present the user with the ability to select which SFDX project to compare / deploy, either by package.xml or sfdx-project.json. Currently Gearset fails and reports multiple sfdx-project.json were found.
[
{
"UserReadableError": "This repository has 2 sfdx-project.json files: Gearset cannot determine which one to use",
"ErrorType": "ErrorFromSource"
}
]2 votes -
Distinguish between process builder and flow
If you do deployments of flows and processes from process builder, both of them are handeled as a flow. If you need to activate the flow or process manually in a production org, you need to guess if it was a flow that you have deployed or a process.
Please within the deployment report (and the comparism), distinguish between flows and processes.2 votes -
Improve CI validations jobs - allow incremental comparisons with Github Pull Request/Push Validations
Currently, the only way to validate a branch, push, or pull request is to essentially have gearset pull all metadata from the repository and the org.
This can result in a long wait time for validation. It'd be great if we could have quicker turnaround for users to get feedback after a push/pull request.
Since github/provider of choice would have the exact metadata that changed in the push/pull request, it'd be helpful to only have gearset pull the metadata that actually changed to limit how much time is spent simply pulling all metadata to make the comparison.
2 votes -
Include Apex classes imported into LWC
Ensure that Apex Classes imported in LWC javascript files are included in dependencies.
2 votes -
Ability to Compare metadata filters
When we have too many metadata filters, it is getting hard to keep track of them and figure out the similarities between them. It would be great to have an option to compare custom metadata filters.
2 votes -
Add 'run selected tests' in nightly scheduled Unit Tests Jobs.
We can select which tests run in Validation. It would be great if we could do the same in a nightly monitoring job.
2 votes -
facilitate selection at the UI of related permissions for selected items during deployment
Our typical use case surrounding related permissions for selected components (application visibilities, class accesses, field permissions, layout assignments, object permissions, page accesses, record type visibilities, tab visibilities) is to need to ensure that if a component is selected, its related permission is always selected also, with respect to a target set of profiles. We suggest you provide an affordance at the UI that selects related permissions en masse rather than requiring individual mouse clicks for each permission selection as at present.
2 votes -
Export test run history
Exporting the Test run history to Excel/CSV will allow keeping trends.
The ultimate goal is to include this in a dashboards. If an embedable web page could be generated with solely the trends, that would be perfect.
2 votes -
Distinguish between code changes and just API metadata changes for Apex in Comparison Window
For large code comparisons, it'd be great to have the ability to see when it's just a change in API vs. actual differences. Right now, you'd have to click on every row to see what the actual change was.
2 votes -
Webhook trigger when Pull Request is Completed in Azure DevOps
Continuous Integration job to trigger when a Pull Request is Completed in Azure DevOps
2 votes -
Add the option to note successfully deployed components in CI notifications
When a CI job is configured to post to slack, and a job fails, it is very useful to see the message posted with information about what failed (error message, number of components that failed).
However, when a CI job succeeds, it only shows the counts of changed/new/deleted objects.
It would be very useful to have the option to list out what was deployed - this would make it easier for devs/qa users who monitor these slack notifications to understand which deployments are relevant to them at a glance.
2 votes -
Pulling object dependencies during data backup
A cool feature would be the ability for Data backup to have the ability to select object dependencies when you select a particular object for instances where you want to backup a subset of data and not just your entire org
2 votes -
Add an option to share orgs by default
Where we have a developer-manager, and a team of developers, it would be useful to be able to have a default for sharing org-connections where the manager always has access to their team's orgs.
At the moment, we have to share each org one-by-one.
This has caught us out where a dev team member validated a deployment, then went on holiday thinking that we could deploy it for them. They forgot to share the org-access, so we had to recreate the deployment to get it done.
2 votes -
Mark items as already reviewed earlier
Today we are gearing up for a major deploy so we are deploying many different changes into gitHub. It would be nice to be able to mark whole sections of content as already reviewed such that any new comparison could ignore all of that content. Then we could look at only the new or newly changed/deleted content.
2 votes -
2 votes
-
Allow reauthorization of git/Bitbucket tokens used by CI jobs
Currently, if the OAuth tokens used for a Bitbucket integration are refreshed, any existing CI job will not adopt the newly authorized token. In fact, there is no way to even edit the job to use the new credentials; the job must be completely deleted and created anew.
However, in the case of Salesforce OAuth tokens, Gearset already has a Reauthorize button, along with facilities for re-associating the new credentials with saved orgs and saved CI jobs. Please enable similar reauthorization mecahnics and credential saving for other Oauth integrations, especially Bitbucket Server, so that CI jobs will not need to…
2 votes -
Allow the use of cached metadata during comparisons
Over the past 2 days we ran multiple comparisons between salesforce orgs. Nothing was changed in the target org but some fixes were applied to the source org in order to make the deployment successful. A lot of time would be saved if we had the option to compare the source org to a cached copy of the target org. In this case, the source org was finishing very fast, especially when we used the local file comparison.
2 votes -
Add an option to disable deploying the email to case settings in Case.settings
This will allow to deploy Case.settings without getting this deploy error:
EmailToCaseRoutingAddress[Info]: emailServicesAddress is a read only field and cannot be changed2 votes
- Don't see your idea?