Source Decomposition Options for PermissionSets
#2993
Replies: 11 comments 18 replies
-
📺 Watch PermissionSet Source Decomposition to review the proposed options.↑ Cast Your Vote ↑ |
Beta Was this translation helpful? Give feedback.
-
Option One: Total DecompositionRemember, all new source behaviors are optional. Your source files won't change unless you activate this feature. Proposed Source Behavior
Example↑ Cast Your Vote ↑ |
Beta Was this translation helpful? Give feedback.
-
Option Two: Focused DecompositionRemember, all new source behaviors are optional. Your source files won't change unless you activate this feature. Proposed Source Behavior
Example↑ Cast Your Vote ↑ |
Beta Was this translation helpful? Give feedback.
-
|
@VivekMChawla - I beg of you, whichever method you move forward with. Please make the order of elements in the xml deterministic. ie: please sort them... I just did a code review on a permission set. Developer added perms to a field. But because the retrieve command writes the permset xml ... in any order it sees fit - comparing it against a git version can be quite the chore. |
Beta Was this translation helpful? Give feedback.
-
|
@jongpie - Thank you very much for your feedback. I want to clarify a few things about how
I'm glad you brought up By the way, I highly recommend reading this extraordinary post by @scolladon. It describes the three "types" of possible decomposability with Salesforce Metadata. It helped me wrap my head around this topic when I started digging into it. |
Beta Was this translation helpful? Give feedback.
-
|
@VivekMChawla thanks for the clarification! And for linking to that post by @scolladon. It has some incredibly helpful info, and I wasn't aware of the official terms |
Beta Was this translation helpful? Give feedback.
-
|
I was slightly concerned over additional complexity in managing adding and deleting individual files in version control as perm sets are updated, which is why I voted for the focused decomposition, but I do see the possible advantages for full decomposition outlined above. From a version control perspective, I prefer to keep supporting scripting and manual activities to a minimum which is another reason to go with focused decomposition. Deterministic structuring of the XML itself is very important. |
Beta Was this translation helpful? Give feedback.
-
Reading following reply: |
Beta Was this translation helpful? Give feedback.
-
|
@jongpie - As noted by @horzel those terms aren't exactly "official". They're just a really good way to describe the different options. Tip of my cap to @scolladon for sure! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Total decomposition will result in a very big amount of small files for each permission set. Imagine that you need to review a pull request with quite some permission sets :) |
Beta Was this translation helpful? Give feedback.
-
|
@VivekMChawla thanks a lot for working on this. Dumb question, why do we need to choose? Both options can satisfy different use cases. For example, when comparing diffs for a single change, having a single file to point to would be a dream, and it can also reduce merge conflicts. For comparing overall diffs across 2 perm sets, focused decomposition would help as well. |
Beta Was this translation helpful? Give feedback.
-
|
@pgonzaleznetwork - Thanks for asking this question. Behind the scenes, the CLI does a lot of complex work when converting metadata between MDAPI and SFDX source formats. We want to offer new decomposition options, but each one increases the chance of introducing unexpected issues. Focusing on a single decomposition method per metadata type reduces the surface area for troubleshooting and support. It's our way of balancing the introduction of new capabilities with our commitment to maintaining the stability the CLI. |
Beta Was this translation helpful? Give feedback.
-
|
@pgonzaleznetwork Feel free to use my plugin if you want total decomposition of perm sets. https://github.com/mcarvin8/sf-decomposer If your perm sets are large, this becomes a pain since it will create hundreds/thousands of files. But this is an option for manageable perms if you want to have files for each perm. |
Beta Was this translation helpful? Give feedback.
-
|
@VivekMChawla - implicit in the idea that "Each permissionset-meta.xml source file must be unique inside a project." is the idea that a permission set can only exist inside one subfolder in the project. That is different from the way that Fields and Object metadata can be spread across multiple packages. I do think that's a better design, the potential for confusion is even greater if the permission sets are defined across multiple folders. Total decomposition seems like a disaster. You can see all the names of the fields, but you can't see the permissions unless you open the file. The benefit of defining each CustomField is that they can be spread across multiple packages. THat's not relevant here. Total decomposition seems shortsighted. |
Beta Was this translation helpful? Give feedback.
-
@abd3 - YES! You understood my meaning perfectly! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
@VivekMChawla
Some Elements.cloud-specific questions/feedback, but probably applies to any metadata-scanning product
|
Beta Was this translation helpful? Give feedback.
-
|
@rickroesler - Thank you for engaging and providing feedback!
PS: If you're at DF this year, I hope we run into each other! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Some thoughts on dev experience. Total decomposition reduces the chance for merge conflicts when adding/removing mdt, which is nice. However, keyword pollution on field names, etc. could increase friction during development. Many small files, while providing granular control, can result in a confusing experience. Similar perm sets are defined unique via the path, not filename. We would have to be much more careful to ensure the file being edited is correct by comparing paths, and using the command palette (VS Code) to open files will offer a much larger list of options due to the new naming conventions. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you all for voting and commenting! Based on your feedback, we will proceed with Option Two: Focused Decomposition for I'll now close and unpin this discussion. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@VivekMChawla - I'm not sure if this has been reported by anyone else using the newly released All decomposed
I'm not seeing anything off in https://github.com/forcedotcom/source-deploy-retrieve/blob/main/src/registry/presets/decomposePermissionSetBeta2.json besides the That's a different issue, but decomposed items should be addressable (deployable/retrievable) without the parent in my opinion. I don't know if anyone else has the same issue with |
Beta Was this translation helpful? Give feedback.
-
|
@mcarvin8 - Thanks for highlighting this issue. Would you mind creating a new issue for this, including the screenshot and your notes? I'll work with @WillieRuemmele to prioritize a fix once he's back from holiday PTO on January 6th. |
Beta Was this translation helpful? Give feedback.
-
|
I've been trying to figure out what's wrong with my custom permissions for a few days now, it's good that I came across your message, in my orgs |
Beta Was this translation helpful? Give feedback.
-
|
New issue created here - #3165 |
Beta Was this translation helpful? Give feedback.
-
The design for decomposing
PermissionSetshas been finalized.Thanks to everyone who voted and shared their thoughts regarding the design of a new source behavior option for
PermissionSetmetadata. Based on your feedback, we will proceed with Option Two: Focused Decomposition.The PermissionSet Source Decomposition video remains available for anyone who'd like to see examples of "Focused Decomposition."
You can also review the details of the Focused Decomposition design (Option Two), below.
Thank you all for your feedback!
127 votes ·
Beta Was this translation helpful? Give feedback.
All reactions