Jonathan Keener
My feedback
22 results found
-
11 votes
An error occurred while saving the comment Jonathan Keener
supported this idea
·
-
1 voteJonathan Keener
shared this idea
·
-
12 votes
An error occurred while saving the comment Jonathan Keener
commented
Where Gearset handles this better than changesets is that it can "retrieve" metadata but you don't have to deploy it. With a changeset, you don't have this flexibility.
What I've done is create a custom "Full Profile" filter, that pre-selects all profiles and then all related metadata that could impact these. (For example, Custom Objects, Apex, etc.) I then modify it to include only the Profiles I'm deploying. I then execute the compare.
When the compare results come up, if they are new profiles, I select them, and if they are updates to existing, I search for "permission" and "visib" to locate the specific profile items related to profile settings and select them for deployment.
This is a little cumbersome, but does get the bulk of the profile deployed.
I agree that there is a big opportunity here for a more streamlined process for deploying profiles, since they are relatively unique in that you have to retrieve related metadata to gather proper security around them. I would love to see a process that handles this type of deployment automatically by selecting the profiles and indicating that a "full retrieve" needs to be done. The profiles could then internally be retrieved in separate batches and the extraneous metadata retrieved removed from compare. (Other metadata explicitly selected would stay)
Jonathan Keener
supported this idea
·
-
2 votesJonathan Keener
shared this idea
·
-
1 voteJonathan Keener
shared this idea
·
-
1 voteJonathan Keener
shared this idea
·
-
13 votes
If we implemented this and it was only able to search metadata from that point in time onwards, would that be useful or would it be confusing to communicate in the UI?
Jonathan Keener
shared this idea
·
-
1 voteJonathan Keener
shared this idea
·
-
13 votesJonathan Keener
supported this idea
·
-
1 voteJonathan Keener
supported this idea
·
-
3 votesUnder review · 2 comments · Help us improve Gearset » Comparisons and difference visualization · Admin →Jonathan Keener
supported this idea
·
-
3 votesJonathan Keener
supported this idea
·
-
5 votesJonathan Keener
supported this idea
·
-
2 votesJonathan Keener
supported this idea
·
-
1 vote0 comments · Help us improve Gearset » Integrations and connections (Jira, source control, DX etc.) · Admin →Jonathan Keener
supported this idea
·
-
5 votesJonathan Keener
supported this idea
·
-
4 votesJonathan Keener
supported this idea
·
-
17 votesJonathan Keener
supported this idea
·
-
31 votesJonathan Keener
supported this idea
·
-
1 vote
An error occurred while saving the comment Jonathan Keener
commented
Another possible solution for this would be to allow manual editing of the "Source" XML prior to deployment. In my specific case, I'm currently needing to fix two items. First, in deploying some Duplicate Rules, issues are thrown based on the "Sequence Order". Second issue is a poorly written AppExchange component (Home/Child Kanban) that is storing an Internal Id in the Metadata that doesn't exist in the target.
Jonathan Keener
shared this idea
·
I would love this! It initially shows just those pre-selected but then it loads the entire list. I'd love a way to filter back to having only those included in the deployment pre-selected, as that is the typical use case/starting point when choosing "Specify which tests to run" and then maybe adding an extra couple as needed.