Deploying a report fails when using Deploy All Metadata

[René Görgens]

Hi Scott,

I’m trying to deploy metadata to the project connection, namely a report:

If parent subscribed (A)

• Selecting custom in the deployment scope, screenshot below

If directly subscribed (B)

• Leaving deployment scope on context

If using Deploy All Metadata (1)

• for (A): Error: “Deploy - ComponentSetError - No source-backed components present in the package.”
• for (B): package.xml: ERROR at line 1, column 1 - An object 'unfiled$public' of type Report was named in package.xml, but was not found in zipped directory

If using Deploy Modified Metadata (2) (which I’m otherwise never using)

• for (A): Works fine
• for (B): “All files are up-to-date.”

Summary:

• I was able to deploy report with subscription type (A = parent) by using method (2 = Deploy Modified Metadata)

• I wasn’t able to deploy report with subscription type (B = direct) with either:

  • (1 = Deploy All Metadata), results in error or
  • (2 = Deploy Modified Metadata), nothing is deployed.

I’ll send you the logs for 1-A (error), 1-B (error), 2-B (nothing deployed) by email. 2-A succeeded but I didn’t capture the log (upon retry result is 2-B).

‌

‌

[René Görgens]

I was able to reproduce issues 1-A and 1-B on another machine, in a project based on the same repo.

[Scott Wells]

Yeah, this is a corner-case where foldered metadata objects in the system's special unfiled$public folders can be retrieved and deployed, but that folder doesn't have a companion meta.xml file like other folders. IC already had a filter for that for email templates, but not for dashboards or reports. I'm quite surprised no one else has run into this previously (or at least run into it and reported it).

I've just committed a fix for inclusion in the next build.

[Scott Wells]

Delivered in 2.3.0.2.

[René Görgens]

Re-test:

• (B) Succeed: Thank you for fixing the issue with unfiled$public, that works like a charm now

• (A) Fail: I’m still getting this error when trying to deploy the same report (List_of_donations_received_on_ULs_accou_Gpd.report-meta.xml):

  • “Deploy - ComponentSetError - No source-backed components present in the package.”
  • I cherry pick this report for using Custom scope in the deployment dialogue (cf. above screenshot). It is actually in package.xml: <members>[...]/List_of_donations_received_on_ULs_accou_Gpd</members>
  • I can refresh the report but I cannot deploy it using Deploy All Metadata

‌

[Scott Wells]

I’m a bit confused by the scenario that’s still failing. I’ve tried to reproduce it and have been unable to do so. Here’s my metadata subscription:

‌

Here’s the custom selection for deployment:

‌

And here’s the result of that deployment:

Deployed 3/3 components to demo in 3 s 762 ms with status SUCCEEDED.

Successes
=========
- package.xml
- reports/MyReports.reportFolder-meta.xml
- reports/MyReports/AccountReports.reportFolder-meta.xml
- reports/MyReports/AccountReports/New_Accounts_Report_iXv.report-meta.xml

I think that effectively models what you’re saying isn’t working.

The one thing that comes to mind is that perhaps you have a missing -meta.xml file for one of the report folders. Can you confirm that both folders have a <Name>-reportFolder-meta.xml file? If not, can you add the missing one(s) and see if that doesn’t resolve the issue?

[René Görgens]

Thank you Scott.

The report folder’s -meta.xml file exists but it’s a subfolder. I’ve noticed the following:

• In 2.3.0.0, the subfolder was shown under reports as ‘folder/subfolder’
• In 2.3.0.2, the subfolder is now shown as ‘folder’ only

The -meta.xml file has not changed of course, I didn’t refactor it and version control would show a change.

I’ll re-test this further with a simple project and let you know.

[Scott Wells]

Yeah, see if you can reproduce this behavior in a simple, standalone project that can be shared. I have a number of nested report folders and am not seeing any issues with them. If you’re finding that you’re no longer seeing report sub-folders properly, that would be a bug for sure.

[René Görgens]

I tried with a fresh project with some arbritrary report folders and I see the same as you do: correctly nested report folders:

‌

However on the existing project in which I encountered the issue, I have an anomaly with the org. Even when retrieving reports into a new project:

• (Any report folder I created myself: nests correctly and deploys alright, reportFolder-meta.xml available)

• Report folder ‘CompanyDashboards’ visible in metadata retrieval (screenshot below) is NOT visible in Reports tab UI and does NOT nest locally. Its subfolders are listed as top level (both in the org and locally) and the reports they contain can be retrieved and refreshed, but not deployed (“Deploy - ComponentSetError - No source-backed components present in the package.”). All reports at any nesting level in ‘CompanyDashboards’ behave like a one-way street and the folder itself is hidden.

  • The setting Enable the Unified Experience for Analytics Home was ON, but deactivating it doesn't change the issue

So it’s a very specific issue with ‘CompanyDashboards’ existing but not being visible, and apparently not having an associated reportFolder-meta.xml

‌

[Scott Wells]

Interesting. Do you see any change in behavior if you install the build posted to #2513? That’s a fix for a bug in this specific area that was raised almost immediately after I posted 2.3.0.2 this morning, and I’m wondering if perhaps it’s affecting you in this specific project as well.

[René Görgens]

Thank you Scott. I tried this build and re-tested the scenario:

• No change, subfolders of CompanyDashboards (AAAAA, BBBBB -- masked) are shown as top level folder, refresh works, deploy fails
• However I paid more attention to the retrieve results:

Retrieved 18/19 components from [connection] in 21 s 121 ms with status SUCCEEDED.

Successes

• reports/AAAAA.reportFolder-meta.xml
• reports/AAAAA/Accounts_by_Type_of_Donor_LR2.report-meta.xml
• reports/AAAAA/Closed_Won_Opportunities_2022_wO6.report-meta.xml
• reports/AAAAA/Closed_Won_but_not_Received_5Nc.report-meta.xml
• reports/AAAAA/Companies_Foundations_UFG.report-meta.xml
• reports/AAAAA/List_of_donations_received_on_ULs_accou_Gpd.report-meta.xml
• reports/AAAAA/List_of_donations_to_be_received_by_UL_gen.report-meta.xml
• reports/AAAAA/New_Opportunities_Report_ZdY.report-meta.xml
• reports/AAAAA/Opportunities_by_Account_D71.report-meta.xml
• reports/AAAAA/Opportunities_with_contact_roles_lys.report-meta.xml
• reports/AAAAA/Principal_Project_Owner_Report_nrL.report-meta.xml
• reports/AAAAA/Thank_You_Letters_eFy.report-meta.xml
• reports/BBBBB.reportFolder-meta.xml
• reports/BBBBB/Closed_Won_Opportunities_ghT.report-meta.xml
• reports/BBBBB/Copy_of_New_Opportunities_Report_ADt.report-meta.xml
• reports/BBBBB/Current_Funnel_Report_gZM.report-meta.xml
• reports/BBBBB/New_Opportunities_Report_1bS.report-meta.xml
• reports/BBBBB/To_delete_6Wa.report-meta.xml

Failures

• package.xml: Entity of type 'Report' named 'CompanyDashboards' cannot be found

‌

[Scott Wells]

Gotcha. No surprise, honestly, but since I saw an issue in this area – and provided a fix for it – just this morning, I figured it was worth a shot. I think the best way for me to get my head wrapped around what’s going on is if you can reproduce the issue in a standalone project that can be shared. Obviously I know that can be a difficult proposition, but perhaps it might make sense to create a scratch org and build up modeling that org’s reports as closely as possible until (hopefully) you run into the issue again, then you can neuter those reports so that the project can be shared.

[René Görgens]

I have no hope of being able to recreate this special hidden folder myself in another org, and asking the client to consent to diagnostic access is not currently an option. What I can do is open a case with SF and ask them what kind of report folder that is, invisible, non-retrievable, hence non-deployable hence unusable in any kind of lifecycle. (The simple pragmatic solution is of course to move the reports somewhere else.) Maybe in their millions of support cases they have a precedent or they can offer an explanation.

[Scott Wells]

Well, perhaps a first step before logging a support case with Salesforce might be trying to reproduce the behavior outside of IC to see whether it’s an IC bug (it may well bug) or something else. What happens if you try to deploy a report under that folder directly from the CLI, specifically using a package.xml file since that’s what IC uses to deploy even if it’s a selective deployment. Note that if you enable logging of CLI commands in Illuminated Cloud | Configure Application | Salesforce DX, you can see the exact command that’s being executed including the path of the generated package.xml file. That would allow you to try to corner this a different way.

[René Görgens]

Thank you Scott, I enabled the CLI command logging. Executing the command manually yields exactly the same result, so it’s not IC related.

I’ve opened a case with SF, let’s see what they say.

[Scott Wells]

Well, there’s still a chance it’s an IC2 issue since IC2 is generating the package.xml file that’s being used. Do you mind sharing that file either here or via email? Based on its contents, I’ll likely have you confirm other things existing in the project directory structure, and I may have you make some changes to that file and retry the deployment directly via the CLI to see if certain changes resolve the issue or not.

[René Görgens]

Of course Scott, I’ll send you the files by email.

[René Görgens]

Hi Scott,

To give you an account what happened with the Salesforce case that I raised.

• The root cause of the hidden folder wasn’t determined. In principle I only had access to standard support; the account executive authorised developer support but the investigation depth was somewhat limited.
• I found 4 Classic report folders that had been created with the org and are inaccessible but they are not a factor it seems. The following query identifies 15 report folders with blank Name/ DeveloperName, out of which 11 are accessible via Classic and 4 are inaccessible:

SELECT FIELDS(ALL)
FROM Folder
WHERE (Type = 'Report') AND (DeveloperName = '')
ORDER BY Name
LIMIT 200

• Support used tools which retrieve metadata (workbench) but none which enumerate metadata (reports/ report folders) and present them to the user for selection. Unsurprisingly, they could thus not see the ‘CompanyDashboards’ folder because that is only visible in the enumerated catalogue, not locally after retrieve.
• The workaround is moving the reports residing in visible subfolders of the invisible ‘CompanyDashboards’ folder somewhere else e.g. from folder ‘/CompanyDashboards/FolderA' to ‘/FolderA_1' (using the UI).

So this is where the case leaves me.

Out of interest, I’d like to be able to have a reproducible set of steps which is independent of IC, exhibiting the problem using only Metadata API calls. But I haven’t advanced on that – either identified a tool which can do this or accessed the MDAPI directly; for the latter I don’t think I have the time/skill at the moment.