Sfdx-git-delta: Fix CustomWebLinks metadata processing

[jjulicher]

What is the problem

---

When there are CustomWebLink components in the metadata in source format and pulled using SFDX it pulls them with the custompageweblink-meta.xml suffix. The documentation states it is a .weblink suffix which doesn't actually happen.

e.g.

ClientStore.custompageweblink-meta.xml

expected as per documentation:

ClientStore.weblink-meta.xml

Custom Page Web Link Apex Doc
*Operating System: Windows 10
*NPM version: 14.9

**Node version: 6.14

**sgd version: 3.3.1

Optional more information

---

As per the PR request.

[scolladon]

After reading the documentation here is what I understand.

CustomPageWebLink are metadata representing Custom Button created for classic Home Page Component. They are stored in a webLinks folder at the package root directory.

WebLink are metadata related to CustomObject. In the metadata format it is contained in the CustomObject file. In the source format it is contained in a sub folder of the CustomObject.

This is a little bit annoying, as they both have the same parent folder name (but not at the same level in the package directory), because the handler selection is done based on the folder name... So with the current implementation it is not possible without changing the code for this particular to make it works for both.

I wonder if we should implement support for CustomPageWebLink as this is a metadata related to classic and not used in Lightning anymore because home page are flexipage now.

Opening the debate here

[jjulicher]

Ok,

Sorry it's been a long week and my original issue description I confused with the report type PR I submitted.

I think I know what's going on. SF Documentation is incorrect and doesn't represent what the CLI actually pulls down.

I pulled all our source using sfdx force:source:retrieve -x manifest/package.xml -u user

the files came through as customwebpagelink-meta.xml not as the expected weblink-meta.xml as per the doco but they were under the weblinks folder.

Hence my fix to use the customwebpagelink as the fix would be correct for the new source format. I'm not sure what the old format pulls them down as.

We need to submit a bug fix to SF to resolve the issue by either updating the docs or the CLI to pull them down as weblink-meta.xml. I'm thinking they will update the documentation as it would be a potential breaking fix if they update the results.

[jjulicher]

I just checked a retrieve via mdapi and the files come through as .weblink. So there is a discrepancy with source format vs old format.

[jjulicher]

Logged with the sfdx cli here:

https://github.com/forcedotcom/cli/issues/606

Although I'm thinking they are going to come back as 'Working As Designed' in their response. As the source format doesn't align in a lot of ways to the MDAPI format. Would be good if they documented these differences somewhere though.....

[jjulicher]

Doesn't look SFDX team are going to respond to my issue.

How do you want to proceed @scolladon?

[scolladon]

@jjulicher As it is a metadata used in Salesforce classic, as it requires a little bit of refactoring in sgd, as you found a workaround for your CI init and as the sfdx team is not responding, I propose to let this issue open to see if someone else is interested in this feature.
If it is the case we will consider it strongly.