2.2.9.2 release notes

2.2.9.2

Issue 2464 - Added support for the missing lightning-select LWC component.
Issue 2469 - Fixed an issue with a few Knowledge__DataCategorySelection field data types that are reported as DATACATEGORYGROUPREFERENCE but should be represented in Apex as String and in ES6/TypeScript as string.
Issue 2472 - Fixed an issue with incorrectly reported Active status indicators for picklist field values in OST custom field ApexDoc. It looks like at some point the API stopped returning a non-null value for isActive for active picklist field values, and IC2 was interpreting null as meaning inactive.
Major metadata subscription management changes/enhancements - As promised in the release notes for the previous two builds, this build includes significant changes/enhancements around metadata subscription management. Please read the following carefully to understand how and/or whether these changes might affect your projects (hopefully all for the positive):
- The Selected and All/Package metadata subscription types have been removed. Projects with those subscription types are automatically updated to use the new Local Files metadata subscription type. Note that the All/Package type had already been effectively removed for all but those already configured against development packages. Wildcards from Selected subscriptions are migrated to the resulting Local Files subscription resulting in what should be a functionally identical metadata subscription, albeit maintained automatically by the project's local metadata files instead of explicitly. The end result is that IC2 now supports only Package.xml (explicit) and Local Files (implicit) metadata subscriptions for all projects, and projects configured against source-tracked orgs use a read-only Local Files metadata subscription since source-tracking is responsible for reconciling the local vs. org state.
- The metadata subscription editor can now assist with updating local project files when the metadata subscription contents have changed (again, non-source-tracked orgs only). By default this behavior is enabled only for Local Files metadata subscriptions but can be enabled or disabled as desired using the following new configuration options under Illuminated Cloud | Configure Application | Validation and Deployment | Metadata subscription:
  - Retrieve subscribed metadata files for [All|Local Files only|None] - Determines the metadata subscription type(s) for which IC2 will prompt the user to retrieve missing subscribed metadata when applying metadata subscription changes. Defaults to Local Files only.
  - Remove unsubscribed metadata files for [All|Local Files only|None] - Determines the metadata subscription type(s) for which IC2 will prompt the user to remove local metadata files that are no longer part of the configured subscription when applying metadata subscription changes. Defaults to Local Files only.
  - Remove unsubscribed child metadata for [All|Local Files only|None] - Determines the metadata subscription type(s) for which IC2 will prompt the user to remove local child metadata XML tags that are no longer part of the configured subscription when applying metadata subscription changes. Defaults to Local Files only.
  Note that the default settings of Local Files only for these options were selected to minimize disruption to existing users, but my goal is to change the defaults to All in short order pending a bit of burn-in time (and the likely resulting bug reports/fixes).
  IC2 tries to maintain integrity of local project files when adding and removing local metadata files and elements:
  - When adding child metadata objects, if necessary subscribed parent and sibling metadata objects are automatically included in the retrieval to ensure that they are not lost.
  - Removal of local metadata files and XML tags for non-decomposed child metadata objects can be reverted via the IDE's standard Undo action if desired with one notable exception. At present, I can't seem to include removal of local binary files in the IDE's undo buffer properly, and they are restored without their contents. As a result, if binary files would be included in the removal, the user is prompted as to whether to include them, exclude them, or cancel the action altogether. I have an inquiry with JetBrains now as to how I can include binary files without this issue and, if/when I am able to resolve it, the corresponding prompt will of course be removed.
Major Salesforce CLI connection cache management improvements - Raise your hand if you've been annoyed by how often you see a modal progress indicator about IC2 loading the org list and/or details from the Salesforce CLI. Wait...not everyone all at once!!! Yeah, yeah...my hand is up as well.
I've tried to address this a few different times and a few different ways, but the results have never been all that great. Well, I'm hoping this time is different and the issue is finally resolved, at least as much as it can be given that the CLI is the system-of-record for those connections. With these improvements, IC2 should only execute the force:org:list CLI command:
- When it doesn't yet have a cache of CLI-based connections.
- When its cache of CLI-based connections is determined to be stale because the relevant subset of JSON files under ~/.sfdx have changed due to additions, removals, or modifications to specific JSON properties that IC2 requires in the respective files.
- When the user explicitly requests a connection list refresh in the IC2 connection manager.
- When the user explicitly adds or removes a CLI-based connection in the IC2 connection manager.
IC2 should only execute the force:org:display CLI command when an API request using an org's CLI-managed access token fails due to an invalid session ID, and only to have the CLI refresh the access token. All org details are now sourced from the output of the force:org:list command.
NOTE: The default session (and therefore access token) timeout is two hours. As a result, by default IC2 would potentially need to execute force:org:display once every two hours to maintain a valid session ID, though actions performed using the CLI help to keep the session fresh. If you'd prefer to minimize the need for this, you can configure the org's session timeout as follows:
- In the org under Setup | Security | Session Settings | Session Timeout | Timeout Value.
- In the scratch org definition file as:
```
"settings": {
  "securitySettings": {
    "sessionSettings": {
      "sessionTimeout": "value"
    }
  }
}
```
  where value can be one of:
  - FifteenMinutes
  - ThirtyMinutes
  - SixtyMinutes
  - NinetyMinutes
  - TwoHours
  - FourHours
  - EightHours
  - TwelveHours
  - TwentyFourHours
  This can also be specified in the IC2 scratch org creation dialog's Settings JSON editor field by omitting the outer settings property.
  As always, there is a trade-off between convenience (longer values) and security (shorter values).
Given the relevance of that setting to the overall user experience, I am considering adding session timeout as an explicit scratch or configuration option where the last selected value is retained across usages.
If you see these CLI commands being executed more frequently than described, please let me know so that I can gather diagnostic information and tune as needed to achieve the desired behavior.
Fixed an issue that could result in an end user-facing error message of "You must call login() first." Now that situation results in IC2 automatically re-authenticating and retrying the requested operation with a fresh session.
Fixed a regression in LWC ES6 type inference for call expressions introduced with the 2023.3 pre-release changes.
Implemented a potentially significant performance optimization for the ApexDoc validation code inspection when evaluating Apex source files that include large numbers of ApexDoc type/member references.
Improved the Apex Invalid type code inspection's logic for determining that a type has incorrect type parameters.
Quite a few other related fixes and improvements.

Search This Blog

Illuminated Cloud Announcements

2.2.9.2 release notes