fix: adds support for nested InFolder metadata types #455
Conversation
| public getFolderContentTypes(): MetadataType[] { | ||
| if (!this.folderContentTypes) { | ||
| this.folderContentTypes = []; | ||
| for (const type of Object.values(this.registry.types)) { |
There was a problem hiding this comment.
Do you think this is why the registry has so many other properties? To avoid the perf hit of iterating over every type just to find some that have a property defined? Would it make sense to add a folderContentTypes property to the registry and just access it directly?
There was a problem hiding this comment.
By "so many other properties" are you referring to the indexes like suffixes, strictDirectoryNames, and childTypes? If so, yeah that's for better perf. There are only 4 folderContentTypes so I don't think it's worth indexing them. Building the array once makes sense to me though. I think RegistryAccess could use more memoization logic like this.
There was a problem hiding this comment.
yeah exactly. I'd prefer not to iterate over the whole registry to find four entries, multiple times... but we could do this optimization later
There was a problem hiding this comment.
It's only done once, not multiple times.
| "folderType": "territory2model" | ||
| }, | ||
| "territory2": { | ||
| "id": "territory2", | ||
| "name": "Territory2", | ||
| "suffix": "territory2", | ||
| "directoryName": "territories", | ||
| "inFolder": false, |
There was a problem hiding this comment.
Adding these back since they are returned by a describemetadata call, and that's what we should be using as the source of truth for type definitions.
| if (!this.strictFolderTypes) { | ||
| this.strictFolderTypes = Object.values(this.registry.strictDirectoryNames).map( | ||
| (typeId) => this.registry.types[typeId] | ||
| ); |
There was a problem hiding this comment.
We only need to do this once. The registry data can't change once RegistryAccess is created.
| "folderType": "territory2model" | ||
| }, | ||
| "territory2": { | ||
| "id": "territory2", | ||
| "name": "Territory2", | ||
| "suffix": "territory2", | ||
| "directoryName": "territories", | ||
| "inFolder": false, |
|
|
||
| const isInFolderType = type.inFolder; | ||
| const isNestedInFolder = | ||
| !fullName.includes('/') || members.some((m) => m.includes(`${fullName}/`)); |
There was a problem hiding this comment.
can windows users put \ or \\ in their manifest?
There was a problem hiding this comment.
I don't think that's valid. It's not a file path, which would be OS specific. It's the server-assigned API name.
…tcom/source-deploy-retrieve into sh/nested-inFolder-types-support
What does this PR do?
Properly resolves nested InFolder metadata types and their respective folder container types.
Report, ReportFolder, Document, DocumentFolder, Dashboard, DashboardFolder, EmailTemplate, EmailFolder
What issues does this PR fix or reference?
@W-9739746@
forcedotcom/cli#1173
forcedotcom/cli#1112
Functionality Before
nested InFolder types failed to convert, deploy and retrieve
Functionality After
successful convert, deploy, retrieve
Testing Notes:
Convert, deploy and retrieve the metadata types listed above as well as Territory2, Territory2Model, Territory2Rule, Territory2Type