Retrieve Metadata isnt working

[sarka...@gmail.com]

Hi Scott,

I am trying to retrieve metadata which are in our org and not in the local project and the checkboxes are disabled. I am not sure how to select them. is there something I am missing? 

See below screenshot, the checkbox next to the components are disabled or wont let me select -

[Scott]

A couple of things about that UI.  Since you're using one of the pre-canned views for Contents (Project) it's a read-only view.  Switch to Custom and you can freely select whatever you want.  Because you've unchecked Subscribed Only, it's showing you things that aren't part of your active subscription, but in those pre-canned views only metadata in your active subscription is selected.  If there's metadata you want to pull down, either switch to Custom and select it, or update your subscription to include it and it should be selected.

Let's start with that and let me know whether that helps to get you going.

Regards,

Scott Wells

[sarka...@gmail.com]

Thanks Scott!! The trick was to select custom from the Context drop down. 

It works. Thank you again. 

[Scott]

Glad to help!  You'll definitely want to set up a subscription (generally either via package.xml or explicit selection) for ongoing work to simplify deployment and retrieval operations, though.  Let me know if you're not sure how to do that and I'll be happy to help.

Regards,

Scott

[sarka...@gmail.com]

Yeah, I am not sure how to do that. We are using the GIT / Microsoft Team Foundation Server for version controlling of our code. So, I am guessing when I pulled the project from GIT before I set up a connection to our SFDC Sandbox, the files didn't get subscribed properly. Does that make sense? 

I may have to do it manually. Please let me know what are the steps. 

Thank you for your help. I appreciate it. 

[Scott]

No problem.  In IntelliJ IDEA open File>Project Structure and then under your module find the Illuminated Cloud facet:

You can configure your subscription as All/Package, Package.xml, or Selected.  You'd really only want to use All/Package if you're working against a development package for something like managed package development.  If you already have a package.xml checked in and versioned with your metadata, you might well want to use Package.xml since that will stay current with your team.  Otherwise you can use Selected and check the exact metadata that you want to manage in Illuminated Cloud.  The configured selection will then be used as the working set for your ongoing development, deployment, retrieval, etc.

Let me know if that doesn't help clarify it.

Regards,

Scott

[Allan Hotchkiss]

Hi Scott, new user here.  I am having a hard time deciding what would be best for us - using the Package.xml option or the Selected option.  Maybe I just don't completely understand their differences.  If I select the Package.xml option, do I need to manually keep the package.xml file updated when I add new Metadata to my org?  We are not doing any unmanaged/managed package development.

[Scott]

Hi, Allan.  Coincidentally I just provided some details about this to another user for a different reason.  Here's an extract of what I wrote about each subscription type:

1. All/Package - Use this when you either want everything in the org (almost never) or have selected a development package from the org and want to deploy/retrieve against that development package. Based on the description I gave above, this would be a good option for you because it's "self-maintaining" based on how Salesforce sees the contents of the selected development package.
2. Package.xml - Use this when you have a carefully hand-tailored package.xml file for your project that's also used by automated processes. Again, this seems like a good option assuming that other tools that use package.xml already "do the right thing" at any given time.
3. Selected - Use this when you want to maintain a custom subscription to the metadata only for the IDE.

If you're not using any type of automated metadata management tool that would want a package.xml as input, the Selected option should be fine.  The subscription details are stored in an IDE configuration file that can be shared across the team, particularly with some changes I'll be releasing this week to segregate user-specific config from shared config.

Please let me know if this doesn't answer your question.

Regards,

Scott

[Allan Hotchkiss]

Thanks Scott.  I think this mostly answers my question.  What I am really shooting for is to "subscribe" to a custom set of metadata, making sure we are always refreshing the existing metadata files we are subscribed to as well as checking for newly added metadata that was added to the org directly in Salesforce (new flow, field, object, etc.). I don't want to have developers on my team worrying about directly updating the Package.xml file and would rather rely on Illuminated Cloud to do that.  So I think the Selected option is probably best, right?  Also, I am really glad to hear we'll be able to share selections in a separate file among our team - this seemed like a missing piece to the puzzle.

Al

[Scott]

Yes, the two primary ways to share a managed/cultivated metadata subscription are either are hand-crafted package.xml or an explicitly maintained selection.  Obviously the package.xml lives with your own source code and would normally be shared along with the source code via version control.  The IC metadata selection is stored in the module's .iml file, but right now that's cluttered with other information that is very user-specific.  You can share it today, but you're also sharing state that isn't intended to be shared.  With the upcoming build I've migrated user-specific config out of .idea/illuminatedCloud.xml and the .iml files into .idea/workspace.xml which should never be checked into version control.

In either case the typical workflow should be for a user who has changed the set of metadata for a project to update the package.xml and/or selection to reflect those changes, then check the resulting file(s) into version control to be shared with the team.  Then when other team members update from version control, they'll get the metadata changes along with the corresponding manifest changes.

Hopefully that makes sense.  Let me know if not.

Scott

[Allan Hotchkiss]

I think that answers most of my questions.  It seems like my selections made using IC metadata selection also update the package.xml.  Is that true? Is the reverse also true - when package.xml is updated will it also update the IC metadata selections?  In effect, are they kept in sync? Thanks so much for taking time to answer my questions.

Al

[Scott]

Not quite, Allan.  Selected and Package.xml are two distinctly different subscription types.  Updates to a package.xml file do not ever cause a change to the Selected subscription.  However, if you perform a module or project-level metadata retrieval when using Selected, you'll see the package.xml file in the left-hand side pane of the resulting diff window.  That package.xml does reflect your Selected metadata subscription, albeit with absolutely no wildcarding...everything is spelled out explicitly.  If you wanted to copy/merge that package.xml back into your local source directory, that would be a way of generating a package.xml from your Selected subscription.

In practice, believe that folks who are automating deployment via Force.com Migration Tool or Salesforce DX CLI are expressing their metadata subscription as a package.xml file that's very carefully hand-crafted, and those who aren't should be able to use Selected as a convenience for configuring the subscription.

Clear as mud?  Seriously, though, let me know if I need to provide more explanation on this.  I'm happy to do so.

Regards,

Scott

[Allan Hotchkiss]

Ahh, I see.  Much clearer.  We use an online Salesforce deployment tool called Gearset which doesn't really care about our package.xml.  It offers a similar mechanism to IC Selected metadata subscriptions so to me it seems like a good idea to use the same type of thing in IC - especially if we are going to be able to save metadata subscription selections to a separate version-controlled file to be shared among the team.

I think we'll try just ignoring package.xml (I assume that is safe to do with IC as long as we're using Selected metadata sets) for the time being, allowing it to be updated whenever we do a retrieval.

Hopefully its becoming a little more clearer to me. :)

Thanks again,

Al

[Scott]

You got it.  If you don't have some other reason for caring about a package.xml, just use Selected and don't ever even copy the package.xml that comes back with a metadata retrieval into your local source root.  The downside is that you'll need to keep your selections in sync between IC and Gearset manually.

Regards,

Scott

[sh.j...@gmail.com]

Scott,

I'm am having similar issues. I've subscribed to the metadata and it appears on the screen as Server Only when starting the refresh, but does not pull down the metadata. https://www.screencast.com/t/6XHvsbfYkVv

Please help me out.

[Scott Wells]

Let's try two things. First, please try changing the value for the Contents drop-down from Context to Module or Project. If that doesn't change the behavior, please enable debug logging for metadata retrieval as documented here:

http://www.illuminatedcloud.com/support/debuglogging

reproduce the issue, and send me your idea.log (Help>Show Log in Finder). If that does get things working, please let me know that as well because that would indicate a bug with retrieval when Context is selected.

Regards,

Scott Wells

[ronde...@gmail.com]

Hey Scott, 

Did you manage to find a solution or workaround for the problem shown in the video of sh....@gmail.com? 

I am experiencing the exact same issue at the moment when retrieving layouts/flexipages from the server, but they are not added to my directory. 

Currently using a connection with api version 47 and Illuminated Cloud 2 v2.0.9.7

Kind regards

[ronde...@gmail.com]

Small addition to my question: 

It appears that the retrieval creates a new src folder in the root directory of my project, only for a specific flexipage and a layout. All the other components are retrieved in mdapi/src. 

Looking at the project structure, there is only one source folder configured: mdapi/src. 

My workaround now is to copy content from the new src to the existing mdapi/src folders, but this is not very practical. 

[Scott Wells]

Hi. Can you please enable debug logging for metadata retrieval, reproduce the issue, and send the resulting idea.log* file(s) to sup...@illuminatedcloud.com? You can find the logs using Help>Show Log in Explorer/Finder/Files.

Regards,

Scott

[Adam Stepanek]

Hi Scott, I am experiencing same issue. I am trying to retrieve businessProcess, I have those checked in my subscribtion, but the retrieval process won't find any.

Thanks Adam

Dne pondělí 20. ledna 2020 v 15:57:03 UTC+1 uživatel sc...@illuminatedcloud.com napsal:

[Scott Wells]

Adam, BusinessProcess is a child metadata type of CustomObject. If you expand the "objects" node in the retrieval tree, then expand, say, "Case", you should see a "businessProcesses" sub-node containing the "Case Support Process" business process. Similar with "objects/Lead/businessProcesses/Lead_No_Convert" and the others.

Please let me know if that's not the case.

Regards,

Scott Wells

[Scott Wells]

Sorry, what I said wasn't quite correct. The sub-folder will be named "BusinessProcess" (child metadata type name) and not "businessProcesses" (child metadata collection name). But otherwise it should be as-described in my previous response.

Regards,

Scott

[Adam Stepanek]

Found it, thanks a lot. Can you tell why in the subscription list it is listed as a separate folder, but during retrieval it is child of an object? I guess that the subscription is not 1 to 1 mirror of the project structure, right?

Thanks Adam

Dne čtvrtek 1. července 2021 v 17:53:17 UTC+2 uživatel sc...@illuminatedcloud.com napsal:

[Scott Wells]

The subscription list is effectively a usability facade atop what would normally be a package.xml file, and those files are organized based on a flat list of metadata types. The build options dialog used for bulk deployment, retrieval, and removal more accurately models the actual metadata relationships--which may not match the project structure exactly, especially in a source format project which affords more organizational flexibility.

Regards,

Scott Wells

[Nikita Grigoryev]

Hello, 

Does illiminated cloud 2 support wave metadata (Tableua)? I don't see this type during retrieving metadata.

I'm able download this type of metadata by VS code, but I would like keep using your plugin :) 

I tried different configuration to download not subscribed metadata and a lot of many another ways.

Thanks a lot!

Regards,

Nikita Grigoryev

[Scott Wells]

Hi. Yes, IC2 provides full support for Wave metadata, e.g.:

Subscription

Retrieval

I'm happy to take a closer look at why you're not seeing the Wave metadata in your IDE. That would likely be easier via direct email support so that debug logs, config files, etc., could be exchanged.

Regards,

Scott Wells