2.0.6.3 release notes

posted Jun 3, 2019, 10:22 AM by Scott Wells

2.0.6.3

  • Issue 1299 - Implemented better error handling and recovery when the server throws a GACK while trying to enumerate flow versions in projects using an API version less than 44.0.
  • Fixed an issue where an SFDX module could end up with an inferred connection of type MDAPI making it difficult to choose an SFDX connection without explicitly editing the .iml file.

2.0.6.2 release notes

posted May 31, 2019, 11:39 AM by Scott Wells

2.0.6.2

  • Issue 939 - Browser content is now opened for SFDX modules using force:org:open which should ensure a valid session.
  • Split the Illuminated Cloud>Show Salesforce Setup action into two actions, Illuminated Cloud>Show Salesforce Setup (Classic) (same as the previous action) and Illuminated Cloud>Show Salesforce Setup (Lightning) to access the Classic and Lightning setup UIs respectively.
  • Fixed a potential NPE/IAE when a null module is used to find a builder.
  • Other minor fixes and improvements.

2.0.6.1 release notes

posted May 23, 2019, 10:43 AM by Scott Wells

2.0.6.1

  • SFDX-develop-against-any-org modules now have full feature parity with traditional/MDAPI modules:
    • The Retrieve for Merge action is now available.
    • Namespace translation and deployment/retrieval substitution rules are now available.
  • It's now possible to deploy/retrieve/delete metadata selectively against an OAuth connection from a scratch org module. These actions are available via the toolbar and drop-down/context menus, but the respective keyboard shortcuts are still mapped to push/pull when working in such a module.
    • A new Salesforce DX configuration option, Allow deploy/retrieve/delete operations against scratch orgs (disabled by default), allows these actions to be performed directly against scratch orgs. This can be very useful for comparing the local project metadata to the contents of a scratch org or performing discrete metadata deployments/retrievals when working with scratch orgs, but note that these operations bypass the Salesforce DX source sync API.
  • Salesforce DX projects with both sfdx-project.json and manifest/package.xml files are no longer concretely inferred as SFDX-develop-against-any-org modules. It is now possible to choose either OAuth connections or scratch org connections for these modules, and the module's behavior is then determined based on the type of the selected connection.
  • Several enhancements/fixes for incremental OST generation on successful deployment of SObject/field metadata:
    • Implemented for scratch org push actions.
    • Skipped when deploying/pushing to a connection other than the one configured for the deployed/pushed module.
    • Fixed a few issues with resolution of deployed decomposed SObject metadata.
  • Added missing schema definitions for LWC target configs to the metadata XSD used for code completion and validation of metadata XML documents. Note that due to aggressive caching of XSDs by the IDE, you may need to navigate into the underlying XSD using Ctrl+B/Cmd+B on an existing recognized element to force the XSD to be re-evaluated.
  • Fixed a bug where metadata deployment/retrieval state wasn't tracked properly when deploying/retrieving against a non-project connection.
  • Fixed a bug where child metadata files in decomposed source format structures were incorrectly shown as instances of the parent metadata type in the build options dialog.
  • Fixed a bug where project connections were only being filtered by name and not connection type in the project configuration table.
  • Fixed a number of issues with the Salesforce DX new project and module wizards.
  • Removed the force:org:list invocation that was intended to "warm" the CLI's org list on project open because it could result in a hang when the CLI misbehaves.
  • Other fixes and improvements.

2.0.6.0 release notes

posted May 13, 2019, 8:15 AM by Scott Wells

2.0.6.0

  • Issues 1017 / 1043 / 1064 (likely others) - Fixed all known issues with support for Salesforce DX source format project structure flexibility.
    • In Salesforce DX projects—either against scratch orgs or OAuth connections—it is now possible to organize your metadata as you'd like for the most part with only the few restrictions described in the linked documentation.
    • New metadata file creation actions are now enabled/disabled as appropriate based on the selected context when the action is initiated.
    • A new action for creating a new subdirectory, New>Directory, is now available as appropriate when working in source roots of Illuminated Cloud modules. Previously the standard New>Directory action was renamed to New>Package by the base IDE which is confusing for those without a Java development background.
  • Issue 1238 - A distinct file template is now used when creating a service Lightning Web Component.
  • Issue 1281 - UX improvement to the New Lightning Web Component dialog. Previously the display name was entered first and the tag/service (i.e., metadata) name and JS class name were derived from that. Now the metadata name is entered first and the JS class name and display name are derived.
  • UX improvement to the New Trigger dialog. Previously the SObject type selector was the first focused component. Now the trigger name field is first.
  • Added a new Validation and Deployment configuration option, Sort package.xml entries, which maintains the selected package.xml file's entries in proper lexicographic order as they are added and removed by Illuminated Cloud.
    • This option only applies to modules that use a Package.xml metadata subscription.
    • This option is disabled by default for backward-compatibility.
  • Improved the workflow experience when creating metadata. If so configured, the metadata subscription should be updated before deployment occurs therefore avoiding a prompt to deploy unsubscribed metadata.
  • Fixed a number of issues with handling of deleted metadata, in particular for propagation to the Salesforce organization and automatic maintenance of the metadata subscription. Bulk deletes of full directory structures should now properly infer the correct deleted metadata and handle it properly.
  • Fixed an issue where users would still be prompted to propagate local metadata deletes and renames in scratch org modules even when configured not to push metadata in response to those events.
  • Fixed an issue with missing error details from metadata delete operations.
  • Fixed an issue where the delete propagation dialog could be displayed when there's nothing to do.
  • Fixed an issue that could result in repeated deployment of a Lightning bundle when multiple files are created initially. Now only a single deployment/push should occur.
  • Fixed an issue where deployment of LWC bundles with Jest tests in MDAPI projects would include the Jest tests in the deployment payload, typically resulting in a failed deployment.
  • Fixed several issues with the copy handlers that could result in incomplete/incorrect copies, in particular for LWC bundles, static resource bundles, and static resource files in Salesforce DX modules.
  • Fixed all known issues with automatic metadata subscription management—both Package.xml and Selected—except for those related to support for child metadata types. Those will be addressed in the next major feature build.
  • Fixed an issue with tabbed editors when displaying binary static resource files.
  • Fixed an issue with the structure view in Visualforce/Lightning markup files that seems to have been introduced in 2019.1.
  • Fixed an issue with hyperlinking to deployment errors reported with a line or column number of -1.
  • Fixed a long-standing issue with the deploy/retrieve/delete dialog that could make all metadata seem to be local-only after a session timeout until an explicit view refresh is performed.
  • Removed the visibility portion of the icon for Apex types in the project view. This is consistent with how Java types are displayed in the same view in IntelliJ IDEA.
  • Many other fixes and overall improvements.

NOTE: The changes required for these fixes have been quite extensive. They have also been tested extensively, but it's quite possible—likely even—that regressions (hopefully minor) may have been introduced. Please report any such issues you might encounter via the public issue tracker or support email contact and they will be addressed ASAP.

1.8.4.9 release notes

posted May 13, 2019, 8:14 AM by Scott Wells

1.8.4.9

  • Fix for an NPE during metadata retrieval when a source root-relative path is null.

2.0.5.9 release notes

posted Apr 26, 2019, 10:46 AM by Scott Wells

2.0.5.9

  • Issue 1093 - It is now possible to specify certain connections as "sacred", i.e., confirmation is required before any IDE-initiated operation that could change the associated organization's metadata and/or data. This includes metadata deployment and delete operations and anonymous Apex execution. To prevent accidental modification of these sacred environments, the user is prompted every time one of these operations is requested against an organization with this option enabled. Icons for connections with this option enabled include a lock overlay in the bottom-right-hand portion.
    • NOTE: Illuminated Cloud will not automatically update any existing connections to enable this option. Users are encouraged to audit all existing connections after updating to this release or higher to enable the option for all connections against organizations for which any modification should be explicitly confirmed.
    • NOTE: This option is only available for native Illuminated Cloud connections and Salesforce CLI connections against non-scratch orgs. It is specifically not available for connections against scratch orgs.
  • Improved usability in the scratch org creation dialog/process:
    • The Load Scratch Org Definition action is now a much more obvious hyperlink button instead of a relatively obscure file open button beside the organization name field.
    • The user is no longer forced to save the scratch org definition even if there have been modifications since loading. Instead the user is prompted as to whether to save, and if declined a temporary scratch org definition file is written and used.
    • If a scratch org definition file was loaded, the same name is used by default when the user elects to save the modified scratch org definition.
  • Fixed several issues with deployment and retrieval of foldered metadata in SFDX-develop-against-any-org modules.
  • Improved presentation of error message information when SFDX-develop-against-any-org deployment fails with a header-level error message and no line-level errors.
  • Fixed an issue that could prevent the required namespace prefix from being included in accepted code completions in the SOQL Query and Anonymous Apex tool windows.
  • Fixed a potential NPE that could occur after creating a new project.

2.0.5.8 release notes

posted Apr 18, 2019, 10:41 AM by Scott Wells

2.0.5.8

  • Issue 1277 - Fixed an issue that could prevent scratch org creation outside of an SFDX module/project.
  • Issue 1278 - Fixed an issue that caused OST generation to fail for SFDX modules when launched from the project configuration dialog.
  • Fixed an issue that could occur when the user clicks Cancel when prompted for a scratch org definition file name while creating a scratch org. Now a temporary file is written instead.
  • Fixed an NPE that could occur during new project creation/import.

1.8.4.8 release notes

posted Apr 16, 2019, 10:36 AM by Scott Wells

1.8.4.8

  • Numerous fixes for Salesforce DX projects:
    • It is now always possible to create scratch orgs from within Illuminated Cloud, not just from the context of an SFDX project.
    • Proper handling and presentation of partial success information in SFDX push failure responses.
    • Fixed all known issues with handling of static resources in SFDX projects.
  • Fixed a boundary issue when processing PMD Apex output.
  • Added startup-time validation for the host JRE version. If an unsupported version is detected, the user is provided guidance on how to update the JRE to resolve the issue.
  • Other minor fixes and improvements.

2.0.5.7 release notes

posted Apr 16, 2019, 6:50 AM by Scott Wells

2.0.5.7

  • Issue 159 - Support for creation and use of OAuth connections in Illuminated Cloud.
    • You may now create and manage SFDX OAuth connections using a new toolbar button in IC's connection manager. IC will prompt you for a connection name, org type (optional), and login URL (optional), then will require you to log in via your Web browser. The Salesforce CLI is used for all OAuth interaction and management of the access token.
    • OAuth connections can be used anywhere that configured IC connections can be used and can be configured similarly.
    • OAuth orgs can also be used for the SFDX-develop-against-any-org feature (see below).
    • NOTE: After updating to this version or higher, each project will be upgraded upon opening to include connection type information for each usage of a connection. This ensures that there is no ambiguity when an IC connection name and a Salesforce DX alias match. If you manage your IDE configuration files in version control, please check in these changes and have your entire team, if appropriate, align on a plugin build that includes this change.
  • Issue 1184 - Support for SFDX-develop-against-any-org projects in Illuminated Cloud.
    • The Illuminated Cloud SFDX new project wizard can now create SFDX-develop-against-any-org projects by checking Generate Manifest in the first step.
    • The import project wizard automatically recognizes SFDX-develop-against-any-org projects and configures IC for them as appropriate.
    • The metadata subscription for an SFDX-develop-against-any-org project is automatically set to Package.xml and configured to use the package.xml file created during Salesforce CLI project creation. Subscription management is based mostly on manual package.xml authoring, but IC will prompt to add/remove package.xml entries as metadata files are added/removed in the IDE.
    • For the most part, SFDX-develop-against-any-org projects work exactly like IC projects using configured connections. Specifically the following features are not currently available in these types of projects:
      • Retrieve for merge is not supported because the CLI is responsible for retrieval of metadata directly into the project.
      • Namespace substitution and deployment/retrieval substitution rules are not supported for the same reason.
    • Tooling API-based deployment works for Apex classes, Visualforce pages, individual simple static resources (not bundles), and individual Aura bundle files in SFDX-develop-against-any-org projects. This can often result in much faster deployment times for these metadata types than sending them through the CLI/Metadata API.
    • Static resource bundles in these projects are managed by the Salesforce CLI.
  • Issue 852 - Added an SFDX config option to specify that all push/pull operations against scratch orgs should use the -f flag to disable conflict detection and force overwrite the target copy. This option was added for some users who are seeing consistent false conflicts reported by push and pull operations and, as a result, are having to perform the operation twice each time. NOTE: If you are not seeing this type of issue, you should not enable this config option.
  • Previously an IC SFDX project could have only one module, and it had to be an SFDX module. Now IC's SFDX support is module-oriented instead of project-oriented. This means that you may now have an IntelliJ IDEA project with multiple SFDX scratch org modules, SFDX-develop-against-any-org modules, and/or traditional username/password modules. The correct module-specific behavior should be applied at all times. NOTE: WebStorm does not support multi-module projects, so unfortunately this change only applies when IC is hosted by IntelliJ IDEA Community Edition or Ultimate Edition.
  • The logic to auto-discover IC project/modules is now much more flexible and can find one or more SFDX modules nested below the project root, potentially as peers to username/password modules, and set up the project accordingly. NOTE: WebStorm does not support multi-module projects, so unfortunately this change only applies when IC is hosted by IntelliJ IDEA Community Edition or Ultimate Edition.
  • Fixed a number of issues with static resources in SFDX projects.
  • Removed auto-added null-valued Id fields from the SOQL query results table view.
  • Added startup-time validation for the host JRE and IDE versions. If unsupported versions of either are detected, the user is provided guidance on how to update as appropriate to resolve the issue.

All Illuminated Cloud, all the time...

posted Apr 8, 2019, 10:26 AM by Scott Wells

I'm often asked whether/when IC will ever be my (only) full-time job. I'm very excited to share that, starting next week, it will be! I'm also excited that I'll finally be able to focus on some truly strategic enhancements to IC, technical and otherwise (first-class user guide!).

I'm structuring the work I'll be doing over the next several months (years?) in the wiki. For those missing them, I'll be adding an issue in the public issue tracker for each item for watching and voting. End-user feedback is always appreciated, so feel free to add your thoughts to the linked issues.

I'm REALLY looking forward to this next phase in the evolution of Illuminated Cloud!

1-10 of 85