fix: handling folders during various operations #208
Conversation
| let type = registry.getTypeByName(typeName); | ||
| // if there is no delimeter and it's a type in folders, infer folder component | ||
| if (type.folderType && !fullName.includes('/')) { | ||
| type = registry.getTypeByName(type.folderType); | ||
| } |
There was a problem hiding this comment.
If a member of an inFolder type is encountered like so
<types>
<member>A_Folder</member>
<name>Report</name>
</types>This will be resolved to the folder type related to Report
{
fullName: 'A_Folder',
type: {
id: 'reportfolder',
name: 'ReportFolder'
// ...
}
}
| // build folder related members separately to combine folder types and types in folders into one | ||
| const isFolderRelatedType = type.folderType || type.folderContentType; | ||
| if (isFolderRelatedType) { | ||
| const { name: contentTypeName } = type.folderContentType | ||
| ? this.registry.getTypeByName(type.folderContentType) | ||
| : type; | ||
| if (!folderMembers.has(contentTypeName)) { | ||
| folderMembers.set(contentTypeName, []); | ||
| } | ||
| members = folderMembers.get(contentTypeName); | ||
| } |
There was a problem hiding this comment.
This is the reverse of parsing. If the set has these components:
[
{
fullName: 'A_Folder',
type: {
id: 'reportfolder',
name: 'ReportFolder'
// ...
}
},
{
fullName: 'A_Folder/My_Report',
type: {
id: 'report',
name: 'Report'
// ...
}
}
]The manifest object is resolved to this:
{
types: [
{
name: 'Report',
members: ['A_Folder', 'A_Folder/My_Report']
}
]
// ...
}
src/common/types.ts
Outdated
| folderContentType?: string; | ||
| folderType?: string; |
There was a problem hiding this comment.
These "fields" are a 1-to-1 relationship with each other. Types in folders define folderType to reference its folder type, while folder types define folderContentType to reference the type that it is a container for.
| if (targetFormat === 'metadata') { | ||
| const { folderContentType, suffix } = component.type; | ||
| xmlDestination = folderContentType | ||
| ? xmlDestination.replace(`.${suffix}`, '') |
There was a problem hiding this comment.
This line is this fix for the second quirk during conversion.
| @@ -352,15 +352,17 @@ | |||
| "suffix": "report", | |||
| "directoryName": "reports", | |||
| "inFolder": true, | |||
There was a problem hiding this comment.
inFolder is unnecessary now and considered deprecated, now that we have the two new fields to define folder relationships
| @@ -23,6 +23,7 @@ export type MetadataType = { | |||
| * Whether or not components are stored in folders. | |||
| * | |||
| * __Examples:__ Reports, Dashboards, Documents, EmailTemplates | |||
| * @deprecated use `folderType` to get the related folder type, if one exists | |||
There was a problem hiding this comment.
If this is deprecated are we removing it once we take care of references outside of the changes in this PR ?
There was a problem hiding this comment.
Yeah that's what I was thinking instead of changing it all now.
| }, | ||
| "dashboardfolder": { | ||
| "id": "dashboardfolder", | ||
| "name": "DashboardFolder", | ||
| "suffix": "dashboardFolder", | ||
| "directoryName": "dashboards", | ||
| "inFolder": false | ||
| "inFolder": false, | ||
| "folderContentType": "dashboard" |
There was a problem hiding this comment.
Is folderContentType going to be updated by the describe api script, etc ?
There was a problem hiding this comment.
good catch, I'll update the registry script
| "emailtemplatefolder": { | ||
| "id": "emailfolder", | ||
| "name": "EmailFolder", | ||
| "suffix": "emailFolder" | ||
| } |
There was a problem hiding this comment.
This type doesn't follow the typeName + "Folder" pattern like the rest, so add an override for it
What does this PR do?
Properly handles folder components in the following scenarios:
What issues does this PR fix or reference?
@W-8380700@