Apply Connection to all/multiple modules

[Mark Mindenhall]

We chose to use a git monorepo for our org, and for reasons I no longer remember, we structure the repo as follows:

1. The project root is not a DX project (i.e., no sfdx-project.json file)
2. Most (but not all) top-level folders are DX projects (i.e., with a sfdx-project.json file) that contain a single DX package. We have 29 of these folders so far, and they all exist as IC2 modules within a single IDEA project.

Most of the time, a developer is working with multiple packages, which are all pushed (via sfdx force:source:push) to a single scratch org. Some devs on our team create a new scratch org for every feature/story, others create a single scratch org with 30 days expiration, and reuse it for multiple features/stories for most of the 30 days. Either workflow can work.

Regardless of workflow, there are some aspects of IC2 tooling that are kinda clunky in our project since we have so many modules. For example, in the “Modules and Connections” window (Tools → Illuminated Cloud → Configure Project), whenever we switch to a new scratch org, we need to go through this table and select it for a bunch of modules.

Rather than a table (as above), it would be super cool to have an easier way to associate Modules (all, or a subset) to specific Connections. Here’s an example of how this might be done using an an expandable/collapsible tree widget:

• Connections are the top level, and are initially “collapsed”, with a number showing how many modules are currently associated (e.g., “my-scratch-org-01 (1 module)”).
• Expanding a Collection displays all project Modules as children
• Each child Module would have a checkbox to associate the Module with the Connection
• Selecting a Module under a Connection would also deselect it from any other Connection
• When the user hits Apply, the usual operations would happen (set default username to scratch org alias for affected Modules, set Connection, etc)

‌

[Mark Mindenhall]

I didn’t want to put this in the issue description, but I have implemented a python script that we use to fix issues with the .iml files, including setting the connection. Here's what it does:

1. Fetches the list of all unexpired scratch orgs, prompts the user to select one
2. Finds all DX modules

3. For each DX module, parses, modifies, and writes the .iml file as follows:

   1. Sets the default username for the module to the alias of the selected scratch org
   2. Sets the connectionName value within the Illuminated Cloud facet to the alias of the selected scratch org
   3. Adds excludeFolder entries for the .sf and .sfdx folders in the module
   4. Fixes our test folder in the sourceFolder list. When modules are created, these always end up with isTestSource set to false.

‌

[Scott Wells]

Mark, you can actually do this now using the connection status bar widget. If you click on that widget, click another connection, and click Set as connection for moduleName, it will see that the connection is used by multiple modules in the current project and prompt whether to change for just the one module or for all modules that use that connection, e.g.:

‌

So it’s not quite in the same spot as you’ve identified, namely the project-level IC2 config, but it’s possible to change the connection en masse for all modules in the project as described above. Does that not accomplish what you’ve requested here?

[Mark Mindenhall]

Ah, I’ve never tried it that way…thanks for pointing it out! I’ll give it a shot and add it to our workflow documentation.

That issue aside, it would be helpful to add excludeFolder entries for .sf and .sfdx folders when modules are created. Currently they’re created without this, then the “Verifying modules…” functionality pops up a bunch of notifications with this listed as a problem. Clicking “Resolve” takes care of it, but that’s tedious to do for each module.

Thanks for the quick response!

[Scott Wells]

Agreed on the default exclusions for those directories. I’ve been meaning to do that for a while, actually. I’ll take care of it today or tomorrow.

[Scott Wells]

I’ve addressed both the automatic exclusions of .sfdx and .sf during project creation/import and also made the project-level configuration prompt the user whether or not to update all modules using the same connection when the connection is changed for any one module in a multi-module project where multiple modules use the same connection. These will both be included in the next feature build.

[Scott Wells]

Delivered in 2.2.5.0.

[Mark Mindenhall]

Scott, I'm reopening this one after some further testing. The solution you mentioned to apply a connection to all modules only works after each module has had a connection assigned at least once. When creating a new project, none of the modules have ever had a connection assigned. Here are some details.

Step 1: Create the project

1. Clone our repo (with 29 DX projects/packages)
2. Create a new project from existing sources, accepting all of the folders detected by IC2.

At this point there's a Notification for each module saying "Invalid configuration for module XXX".

From this initial state, when I go to Tools -> Illuminated Cloud, all I see in the submenu are: * Show Coverage Data... * Configure Application * Show meta.xml files

All of the other elements I normally see in that submenu (including "Configure Project") are missing.

Step 2: Resolve a notification for a single module

1. Open the Notifications panel.
2. Find the one for common (our "root" module, declarative only)
3. Click "Resolve"

Now the "Configure Project" UI is visible as in the screenshot, but common is the only module listed. So if I select a Connection and Apply it, there's no dialog presented allowing me to choose to apply the Connection to all modules.

So I think an initial fix would be to ensure that "Configure Project" is available immediately, and with all IC2 modules listed. That way, when we click "Resolve" on a notification, we can select a Connection for any module, then have the option to apply it to all modules.

Thanks (and happy holidays)!

[Mark Mindenhall]

I’m marking this one as Resolved again. I created #2293 as a new issue with more details than the comment just above.

[Mark Mindenhall]

Setting back to resolved.