AdminGearset Team
(Feedback Manager, Gearset)
My feedback
61 results found
-
4 votes
An error occurred while saving the comment -
13 votesAdminGearset Team
(Feedback Manager, Gearset)
supported this idea
·
-
1 vote
An error occurred while saving the comment Hiya, does the release of the feature on https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/36282925-configure-which-problem-analyzer-results-to-use-in make this possible for you now?
-
14 votes
An error occurred while saving the comment What if the target is an org, or a metadata API repo?
Would you want the behavior to be only for SFDX source format repos?
The biggest question I have is "Would you be able to deploy that selection?" I understand that you cannot deploy a field on a object that does not exist. -
19 votes
All - please let us known in the comments which metadata types you would like us to support next with precision deployments. Thanks
-
1 vote
An error occurred while saving the comment What if the custom git repository connection is for BitBucket or Azure Devops? Would a "View on GitHub" button make sense?
-
22 votes
An error occurred while saving the comment While it is not currently possible to view the "User Last Logged in" information, we are able to give an idea of user usage with the new Reporting API. Specifically, the deployment frequency endpoint provides data on every deployment done with Gearset and includes information such as who completed the deployment and when. This would allow you to do some aggregation and understand how often users are using Gearset.
You can find a walkthrough for this feature at https://docs.gearset.com/en/articles/6216345-getting-started-with-the-gearset-reporting-api and try manually querying the API with our dynamic documentation at https://api.gearset.com/public/reporting/docs/index.html
You may find the aggregate endpoint useful as you can specifically query to aggregate by number of deployments by user over time. I hope this helps, but do get in contact with us via the in-app chat if you have any questions on this.
In the meantime we will continue to consider the other information that has been requested
-
16 votes
An error occurred while saving the comment This is now achievable with the release of the Automation API that Gearset has released. Please see the documentation on https://docs.gearset.com/en/articles/6341493-getting-started-with-the-gearset-automation-api
-
24 votes
An error occurred while saving the comment We'd like a bit of clarification on this, when the ask is to "allow the user to add items", would the list of items be pre-populated on the screen for users to select? If so, where would the list of items come from without querying the source and target?
-
1 vote
An error occurred while saving the comment How would Gearset programatically know what format (Metadata or SFDX source) to parse the repository with, other than using the "sfdx-project.json"? file?
-
2 votes1 comment · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
An error occurred while saving the comment Would the suggestion on https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/34803568-ability-to-chose-multiple-targets-for-a-deployment be a better way to address this use case?
-
1 vote
An error occurred while saving the comment The changed on and changed by information comes from the Salesforce Metadata API, when you compare it against an git branch, that information isn't available as it's the org that returns this information for Gearset to show you. I wonder how this could be achieved technically.
-
8 votes
An error occurred while saving the comment If you are using v43 of the Salesforce metadata API to compare and deploy, this should be possible. If you are using v44+, the new Salesforce specification of the latest APIs removed support for that, so to achieve what is being asked here requires Salesforce's API to change before Gearset would be able to support this.
Is using v43 in the metadata filter an option for you? -
6 votes1 comment · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
An error occurred while saving the comment Thanks for the idea. Does connecting via the Custom git repository connection on the https://app.gearset.com/linked-service-connections page help address this use case?
-
1 vote
An error occurred while saving the comment How wide would be considered big enough?
-
1 vote
An error occurred while saving the comment Hi Adah, Can you clarify what you mean by "fields" here? Do you mean Custom Fields on a Custom object? What if your comparison only contained Apex classes, what would be exported in that case?
-
3 votes1 comment · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →
An error occurred while saving the comment Would would something like this help meet your need?
https://docs.gearset.com/en/articles/5432441-pilot-features-gearset-public-api
-
12 votes
An error occurred while saving the comment Would would something like this help meet your need?
https://docs.gearset.com/en/articles/5432441-pilot-features-gearset-public-api
-
1 vote
An error occurred while saving the comment I think the tricky thing would be the definition of "a component":
Would deploying 2 custom field permissions on the same profile X be counted as 2 components (custom field permissions) or 1 component (profile)?
-
12 votes
An error occurred while saving the comment We have thought about this request and have responded in the documentation (https://docs.gearset.com/en/articles/5069914-delta-ci?location=conversation#h_c386626adc) as follows:
Delta CI jobs deploy everything in the source git branch that has changed since the most recent successful deployment from that branch.
The difference displayed in the run is between
- the new metadata items in the last commit on the source branch, and
- the previous commit on the source branch, when the most recent successful deployment occurred to the target organizationThis is the problem with validation only CI jobs: as the validation CI job does not deploy metadata to the target, there is no previous commit which can be used as a substitute to the most recent successful deployment. As a result, we can't generate a delta CI job run in the same way as we can for deployment jobs.
We have considered several options, but we have not identified yet a suitable alternative to compare against. If you can think of any possible substitute. We'd love to hear from you.
Would we want this feature if the username was bob@somecompany.com as well? I think there are some security concerns about authentication credentials being transferrable in this way.