Eric Kintzer
My feedback
-
7 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
2 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
68 votes13 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →
Merging differences between Apex classes and VisualForce pages is difficult to do automatically due to the understanding required by the developer. For differences between two orgs in other object types, Gearset helps you sidestep that with our granular comparison results. This blog post explains more: https://gearset.com/blog/merging-salesforce-metadata
Eric Kintzer
supported this idea
·
An error occurred while saving the comment -
1 vote0 comments · Help us improve Gearset » Problem analysis and deployment failures · Flag idea as inappropriate… · Admin →Eric Kintzer
shared this idea
·
-
1 voteEric Kintzer
shared this idea
·
-
9 votes3 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →
An error occurred while saving the comment Eric Kintzer
commented
I've noticed that deploying a NEW permission set, that Gearset is implicitly fetching the FLS for:
* All custom object custom fields (including excluded managed packages) - regardless of whether edit/read are both FALSE
Gearset does not fetch for NEW PS the FLS for standard objects (standard fields or custom fields)
Thus, behavior is inconsistent. NEW PS should exclude all FLS where both editable/readable are false. This avoids issues where you want a NEW PS to only include fields ready to deploy and not WIP fields.
Eric Kintzer
supported this idea
·
-
1 voteEric Kintzer
shared this idea
·
-
1 vote0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →Eric Kintzer
shared this idea
·
-
4 votesEric Kintzer
supported this idea
·
-
3 votes
This is now possible as long as a filter is applied to the deployment history page.
An error occurred while saving the comment Eric Kintzer
commented
especially if it was select all successes; we search on past deployments using the JIRA ticket and often there are multiple deployments matching a single JIRA that need to be manually checked 1x1 to get to a combine deployment action
Eric Kintzer
supported this idea
·
-
2 votes0 comments · Help us improve Gearset » Problem analysis and deployment failures · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
4 votes0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
2 votes1 comment · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
3 votes0 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
3 votes0 comments · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
1 voteEric Kintzer
shared this idea
·
-
3 votes1 comment · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
-
10 votesEric Kintzer
supported this idea
·
-
6 votesEric Kintzer
supported this idea
·
-
6 votes1 comment · Help us improve Gearset » Comparisons and difference visualization · Flag idea as inappropriate… · Admin →Eric Kintzer
supported this idea
·
An error occurred while saving the comment Eric Kintzer
commented
Particularly useful for CI jobs where some customlabels represent Ids
This would be soooo helpful. We use the fflib Enterprise Architecture pattern wherein there are domain classes for each sobject, service classes (typically by sobject) and selector classes (also by sobject). Plus a common Application.cls.
All it takes is two developers working on stories that both affect the same aforementioned Enterprise Architecture class file and it requires way too much out-of-band work to resolve merges due to timing issues between when the feature sandbox/branch was created and the current master branch.
Since we do PRs before merging into master, the PR reviewer is apt to say "hey, you are wiping out changes I made in master". Though resolvable with GITHub merge it would be best to avoid that step before the PR is presented for review.
Being able to selectively 'not' deploy a block of code from source to target (because target is more current) would be helpful. For us, this is typically just Apex class files but I can appreciate the point about page layouts as well