2.2.8.4 release notes
2.2.8.4
- Issue 2425 - Added support for Einstein GPT for Developers. To be clear, though, as the underlying feature is currently in an early beta-level state, so too should this IC2 integration be considered an early beta. The API used to interact with the backing service is absolutely going to change between now and the final release, and temporary breakages are pretty much guaranteed. I will track these API changes closely and update IC2 as needed to keep the integration healthy, but until the API settles, there will likely be short periods during which it goes from working fine to not working at all. If you run into such issues, please let me know and I'll see what changes are required.
With that preface out of the way, here are the features:- Added the
EinsteinGPTForDevelopers
scratch org feature flag which must be enabled when creating scratch orgs for use with this feature. This feature can be enabled explicitly in non-scratch orgs under Setup | Development | Einstein for Developers. - Added a new Apex code generation option, Generate | Using Einstein GPT, activated using Alt+Insert on Windows/Linux or Cmd+N on Mac. This opens a dialog into which a description of the desired code can be entered by the user. It also includes the history of previously-entered requests and their associated responses, and it allows the user to provide positive, negative, and custom feedback on those responses to help improve the model. History entries can be removed individually or completely via the respective toolbar actions.
- The responses to code generation requests can fall into several categories based on content type and quality:
- Valid body declarations - If the code generation action was initiated from an Apex class, valid body declarations are inserted into that class. If not, the user is prompted for an Apex class into which they should be inserted, either existing or new.
- Valid type/trigger declarations - If full Apex classes, enums, interfaces, or triggers were included in the response, the user is prompted as to whether they should be created as top-level types/triggers or, if generated in the context of an Apex class and valid as inner types (must not contain
static
members or result in more than two levels of nesting), as members of the containing class. If they should be created at the top-level, a unique name must be selected to avoid conflicts. - Valid Apex statements, expressions, etc. - If the generated code is valid Apex (including standalone SOQL and SOSL queries) but not fully-formed body or top-level declarations, the user is presented a dialog from which the generated code can be copied with options to add it to request history, to provide feedback, and to iterate on the request if desired.
- Invalid Apex - If the response does not contain valid Apex, the user is presented a dialog from which the response can be copied with options to provide feedback and to iterate on the request if desired. I have seen invalid Apex manifest in several different ways including valid code for non-Apex languages and textual messages about not being able to provide any response. In my experience, sometimes repeating the exact same request can result in a different (and sometimes valid) response. Hopefully further training of the model will minimize the frequency of these types of responses.
- Added the
- Issue 2432 - Added configuration options to the Anonymous Apex and SOQL Query tool windows to enable/disable prompting when closing tabs with unsaved changes. These are both enabled by default.
- Fixed an issue with Apex constructor generation in a class with no member variables.
- Fixed a long-standing (and very annoying) issue with Apex code completion where invalid/unwanted completions would be offered when typing numeric literals.