2.2.9.9 release notes

 2.2.9.9

  • Issue 2494 - Spring '24 / APIv60.0 updates
    • Updated the API version used for primary communication with Salesforce APIs to 60.0. Note that at present, I have not yet received the API v60.0 SOAP WSDLs from Salesforce. Once those are available, I will update IC2's SOAP client to be based on those WSDLs. However, I have not seen any issues with using the API v59.0-based SOAP client against the API v60.0 SOAP endpoints.
    • Added 60.0 as an available API version number for configured connections.
    • Updated the OST version number to prompt regeneration for system API changes in API v60.0. Note that Salesforce has implemented some caching-based optimizations to the completions?type=apex Tooling REST API in API v60.0 that should result in faster OST generation times than in the recent past. Based on my own measurements, I'm seeing that the response time for that particular API call has dropped from ~1.5-2 minutes to ~30 seconds. Be aware, though, that the very first call to this API against a given org is uncached and therefore slower, but subsequent calls should take advantage of the cache that was populated by the first call.
    • Updated the bundled completions?type=apex Tooling REST API response to be based on the API v60.0 REST endpoint. Note that this response is no longer based on a "kitchen sink" org and is instead based on a more "vanilla" org. As a result, all of the standard Apex namespaces and types that are expected in an org of any arbitrary shape are included, but Apex namespaces and types for optional features are not. This bundled response is only used if a live response cannot be retrieved from the org during OST generation, though, so unless you're encountering an issue with this API in your target org, your OST should accurately reflect the org shape.
    • Updated Visualforce, Aura, and LWC components, functions, modules, etc., for Spring '24 changes.
    • Updated the bundled SLDS CSS and SVG icons to 2.23.1.
    • Updated for new org features, standard value set names, metadata XML file type extensions, etc.
    • Updated all integrated API documentation.
    • Added full support for the new Apex null coalescing operatorexpression ?? defaultExpression which is the short-hand equivalent of the ternary expression expression != null ? expression : defaultExpression:
      • Updated the Apex parser, expression type evaluator, formatter, syntax highlighter, etc. for the new operator.
      • Added a new Apex code inspection, Null coalescing operator usage, that reports invalid usages of the new operator, e.g., on the left-hand side of an assignment, in a query bind expression, etc. This inspection has been added to the bundled code inspection profile; custom inspection profiles that are configured not to add new inspections automatically should be updated to include the new inspection.
      • Added new Apex code intentions for bidirectional conversion between ternary expressions of the form expression != null ? expression : defaultExpression and the equivalent null coalescing expressions of the form expression ?? defaultExpression. These code intentions can be accessed using the Context actions keyboard shortcut (Alt/Opt + Enter) when an eligible expression is selected.
  • Issue 1100 - Added support for editing Salesforce formulas in XML metadata files and string literals passed to FormulaEval.FormulaBuilder.withFormula(formulaText). This is not implemented as a full custom language but rather as a lightweight custom file type similar to IC2's existing support for DataWeave and SAQL scripts. It includes syntax highlighting, simple code completion for formula functions and SObject types/fields, and navigation to referenced SObject types/fields. There is no support for code formatting, syntax validation, etc., at this time. Also note that escaped string literals in XML files, e.g., "text" or 'text', are not detected by this more simplistic parser as string literal values. The XML elements which are enabled for formula editing are those with names matching the pattern .*([fF]ormula|[eE]xpression). If you're aware of other fields that should be treated as formulas, please let me know of them and I'll update the pattern to include them.