would be cool to be able to "ignore" certain differences
would be cool to be able to "ignore" certain differences... e.g. encryption. So if encryption is enabled in a Production Org but not in a Sandbox (not sure if Encryption is possible for SBs), you have a difference for every custom field <encrypted>true/false</encrypted> which is really irritating.
Anonymous
shared this idea
-
James Billings
commented
This would be handy for undeployable stuff such as Admin.ProfileUserPermission.EditBillingInfo...? The ability to add an item in the comparison results to a "never show me this" list (rather than having more complex filters) would be helpful
-
ben patterson
commented
Similar for businessowneruser. Production vs. sandbox will always be different. Maybe drop anything after a period in non-production environments so we still catch actual user changes.
-
Brian Carlson
commented
This would be very helpful. My current use case is that we haven't configured Communities in our new production org. Until we do, our <externalSharingModel> attribute will be different on all our standard/custom objects until we do that. Also, there's a <sorted> attribute on some of our value SetDefinitions. When I deploy from sandbox (true) to production (false) the value never changes. I'd like to ignore that difference temporarily so I can see what significant differences still exist. This is similar to how a some text compare tools can optionally ignore unimportant differences such as spaces vs tabs.
I can see this working by allowing me to define the 'unimportant' list with a set of RegEx. Then I can toggle between ignore vs don't ignore. When they are found, the 'difference' can tell me that only unimporant differences were found. -
Patrick
commented
Being able to ignore specific metadata elements would greatly reduce the noise we have to review during deploys. Ideally, I'd be able to setup a minimal list of ignores that list zero differences between production and a new sandbox. Yes, I could ignore the entire metadata type or component, but that might miss other changes that I do want to deploy. Some examples include:
Connect app: <consumerKey>
Settings: DevHub: <enablePackaging2> and <enableScratchOrgManagementPref?
Settings: EmailAdministration: <enableSendViaExchangePref> and <enableSendViaGmailPref>
Settings: Security: <identityConfirmationOnEmailChange> and <enableSamlLogin> -
Phil Spenceley
commented
Another example, we have some fields with formula Hyperlinks that reference different ids as the org changes. Also, site.com settings have a checksum which is always different. Being able to always ignore these would be great.
-
[Deleted User]
commented
If the sandbox was created from a PROD org that has Shield encryption enabled and where a tenant secret has been generated, then the sandbox will also have the proper <encrypted>...</encrypted> XML. However, for sandboxes like UAT, you might not have done this step and hence that sandbox will not have the XML. Thus, this request can be worked around by making the sandbox "features" aligned with PROD