Allow reading IlluminatedCloud settings/connections from $PROJECT_DIR$/.idea/IlluminatedCloud.xml

[Gobius Dolhain]

Right now connections and settings are only globally configurable. We handle about 80 org connections, mostly in sandbox-production pairs. Having all of them available is detrimental.

When adding multiple IlluminatedCloudConnection nodes under <option name="connections"> in .idea/illuminatedCloud.xml, they show up as "Project connections", but the Event Log shows this:

Invalid configuration for module 'hci-sandbox'
            Module 'hci-sandbox': The following must be configured properly:
            module must have no more than one configured connection

Adding IlluminatedCloudConnectionConfig nodes under <option name="connectionConfigs"> in .idea/illuminatedCloud.xml does nothing.

Allowing connections to be stored in the project directory as opposed to globally gives us at least the (al be it extremely unsafe) option to store connections in version control and to scope them per IntelliJ project.

[Scott Wells]

I'd like to understand the specific problem you're trying to solve. Hand-editing the XML files is not supported and it's not surprising that it could lead to a (perceived) misconfiguration. I'm also extremely hesitate to move connection configs (i.e., definitions) back to project-level because that caused no end of problems when they were there originally.

I am planning to add a notion of "pinned" connections soon which will allow you to designate a set of connections which should always be displayed in between project connections and other global connections. I plan to implement that so that you can have project-agnostic (i.e., global) pinned connections and project-specific pinned connections. The order of display would be:

Project connections
--------------------------
Project pinned connections
Global pinned connections
--------------------------
Global connections

Would that address the issue that you're having adequately in terms of providing quick/convenient access to certain connections on a per-project basis?

[Gobius Dolhain]

That would address part of the issue.

I connect to sfdx orgs through a local proxy server that handles authentication delegation so my connections look like this:

        <IlluminatedCloudConnectionConfig>
          <option name="checkForConflicts" value="true" />
          <option name="connectionName" value="org-sandbox" />
          <option name="connectionType" value="MDAPI" />
          <option name="loginSharingModel" value="SHARED" />
          <option name="loginUrl" value="http://localhost:5678/login/org-identifier/" />
          <option name="organizationType" value="OTHER" />
          <option name="password" value="dfd2" />
          <option name="username" value="org-identifier" />
        </IlluminatedCloudConnectionConfig>

The password field is just one random character because it is required in IC to connect, but is ignored in the proxy server. For us there are no passwords exposed in the illuminated cloud config files, so adding them to version control somehow would be beneficial, so our team doesn't have to add them manually.

I guess I will just have to share the global illuminatedCloud.xml to my team and have them manually update it when new orgs are needed.

[Jonny Power (he/him)]

Just an FYI Scott - editing the illuminated cloud xml is probably more common than expected. We are also editing our xml configuration for connections. It's important to have a programmatic way of changing a projects connection (consider a build task that creates and sets up a new scratch org, deploys, runs anon apex scripts to create test data, then updates your project connection to the newly created scratch org).

[Scott Wells]

Thanks for the insight, Jonny, My recommendation for such a build task would be to have it create the new scratch org with a consistent alias that matches the name of the connection used in that project/branch. That way no updates would be required. The scratch org alias is local to the workstation and can be the same across multiple users even pointing at different scratch orgs.

The contents of illuminatedCloud.xml aren't a published API. They've been relatively stable of late, but they've changed quite significantly in the past and may well change again in the relatively near future based on some changes I'm considering. My guess is that these changes could break any type of script that expects a particular content layout.

If the common alias recommendation above isn't sufficient, let me know and we can talk about how to tackle the problem in a way that doesn't crack open the configuration internals in a fragile manner. I want to support the use cases in a way that is more forward-looking than what should be a relatively private config file.

[Scott Wells]

Issue tracker grooming.