Store HttpResponse header values

Thanks so much to @TrangOul for suggesting this enhancement, providing Apex code snippets for the implementation, and helping with code review!

Core Unlocked Package Changes

New Feature: Store HttpResponse Header Values

• Resolved #561 (reported by @TrangOul) by adding new fields LogEntryEvent__e.HttpResponseHeaders__c and LogEntry__c.HttpResponseHeaders__c that store the full key-value pair for each header set on the logged instance of System.HttpResponse. These fields are now automatically set when using the instance method LogEntryEventBuilder.setHttpResponseDetails(System.HttpResponse).

  • Based on the great suggestion from @TrangOul, each header key-value pair is stored in the format Header: value to match the (HTTP standard). A \n line break is used as a delimiter between each header when there are multiple headers.
  • For orgs that do not want to store the header values (either due to security concerns with storing this information, or other concerns), you can disable this functionality org-wide by updating the new LoggerParameter__mdt record StoreHttpResponseHeaderValues to false. By default, this feature is enabled/set to true
  • The existing fields LogEntryEvent__e.HttpResponseHeaderKeys__c and LogEntry__c.HttpResponseHeaderKeys__c will continue to be populated. These fields store only the header keys, not the header values, and some orgs have existing tests & logic that rely on checking the logged keys. These fields are always populated for instances of System.HttpResponse, regardless of the configuration of the new LoggerParameter__mdt record StoreHttpResponseHeaderValues.

• Updated permission sets LoggerAdmin and LoggerLogViewer to have read access to the new field LogEntry__c.HttpResponseHeaders__c.

  • The permission set LoggerEndUser intentionally does not have access to this field (or any other fields related to HttpResponse or HttpRequest).

• Added new field LogEntry__c.HttpResponseHeaders__c to the FlexiPage LogEntryRecordPage. This field is shown in addition to the existing field LogEntry__c.HttpResponseHeaderKeys__c, shown in the (massive 😅) screenshot below

  

Updated Internal Coding Conventions for Apex if Statements

• Updated ~300 if statements throughout the codebase to simplify checking Booleans from if(condition == true) to just if(condition). A few existing Booleans were also updated to have a default value to avoid issues with null values.
  • This (hopefully) shouldn't impact any functionality in Nebula Logger - the goal of this change is purely to update the coding style used within the codebase to be a bit more concise, based on some feedback received over the last year or so, including a discussion last year with @rmccu in #383 and PR comment from @TrangOul.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.7...v4.11.8

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Oig9QAC
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Oig9QAC
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Oig9QAC
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Oig9QAC

Bugfix For Save Failures When Using Tagging + SYNCHRONOUS_DML

This release fixes issue #526 reported by @cbcruz74 (in discussion #511) - previously, using a combination of Nebula Logger's tagging system + the save method SYNCHRONOUS_DML (shown in the snippet below) would fail, preventing some logging data from being saved.

Logger.info('hello').addTag('world');
Logger.saveLog(Logger.SaveMethod.SYNCHRONOUS_DML);

This was caused by code that relied on the standard field LogEntryEvent__e.EventUuid - part of the tagging system internally used this field to track & create related LogEntryTag__c records for new LogEntry__c records. When using the save method SYNCHRONOUS_DML, the EventUuid is null, which broke the LogEntryTag__c record creation.

A huge thank you to both @JMercie for working on this release (PR #539), and to @cbcruz74 for reporting the issue!

Core Unlocked Package Changes

New Field LogEntry__c.UniqueId__c

• Added new unique external ID field LogEntry__c.UniqueId__c - this field is now used to upsert LogEntry__c records
  • This is populated with a composite key consisting of the fields LogEntryEvent__e.TransactionId__c and LogEntryEvent__e.TransactionEntryNumber__c. The combination of these fields has been implicitly a unique composite key ever since the field TransactionEntryNumber__c was introduced in v4.4.0, but it wasn't being stored anywhere - now it is, in the new UniqueId__c field
• Added the new UniqueId__c field to the FlexiPage LogEntryRecordPage
• Added the new UniqueId__c field to the permission sets LoggerAdmin, LoggerLogViewer, and LoggerEndUser

Bugfix For Save Failures When Using Tagging + SYNCHRONOUS_DML

• Updated LogEntryEventHandler class to leverage the new field LogEntry__c.UniqueId__c for upserting & internally tracking LogEntry__c records and their associated LogEntryTag__c records (instead of leveraging the standard field LogEntryEvent__e.EventUuid)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.6...v4.11.7

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZfaQAG
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZfaQAG
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfaQAG
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfaQAG

New Method Logger.setAsyncContext()

This release introduces a new method & fields to further help with monitoring & troubleshooting of async jobs, using the platform-provided async context interfaces:

1. Database.BatchableContext
2. System.FinalizerContext
3. System.QueueableContext
4. System.SchedulableContext

The new features in this release can be used either in place of, or in addition to, Nebula Logger's existing method, Logger.setParentTransactionId(), to help with identifying logs from related asynchronous transactions.

Core Unlocked Package Changes

New Method Logger.setAsyncContext()

• Added new global method Logger.setAsyncContext(). There are 4 overloads - 1 for each of the platform-provided interfaces:

   void setAsyncContext(Database.BatchableContext batchableContext) {}
   void setAsyncContext(System.FinalizerContext finalizerContext) {}
   void setAsyncContext(System.QueueableContext queueableContext) {}
   void setAsyncContext(System.SchedulableContext schedulableContext) {}

New Fields on LogEntryEvent__e and Log__c

• Added new fields on LogEntryEvent__e and Log__c that are set by using Logger.setAsyncContext()

  New Fields	Description
  LogEntryEvent__e.AsyncContextType__c and Log__c.AsyncContextType__c	The interface of the platform-provided context. Current values are Database.BatchableContext, System.FinalizerContext, System.QueueableContext, and System.SchedulableContext.
  LogEntryEvent__e.AsyncContextParentJobId__c and Log__c.AsyncContextParentJobId__c	The ID of the parent job (Schema.AsyncApexJob) that initiated the async transaction. Used for Database.Batchable, System.FinalizerContext, and System.QueueableContext.
  LogEntryEvent__e.AsyncContextChildJobId__c and Log__c.AsyncContextChildJobId__c	The ID of the child job (Schema.AsyncApexJob) that initiated the async transaction. Used for Database.Batchable.
  LogEntryEvent__e.AsyncContextTriggerId__c and Log__c.AsyncContextTriggerId__c	The ID of the cron trigger (Schema.CronTrigger) that initiated the async transaction.

• Updated FlexiPage LogRecordPage to conditionally show a new page section, "Async Context Details", which also conditionally shows the 4 new fields, shown in the screenshot below (in the red box)
  
• Updated several async classes (including LogBatchPurger and LogBatchPurgeScheduler) to leverage the new method Logger.setAsyncContext()

Internal Code Cleanup

• Eliminated the helper method LoggerMockDataCreator.createBatchableContext() - the underlying mock batchable context class, as well as some new similar mocks for Finalizer, Queueable, and Schedulable`, are now public and can be instantiated directly
  • Having the extra static methods was adding a lot of unnecessary complication & redundant code to expose static methods for each constructor

Pipeline Changes

• Upgraded sf cli (again) to try to resolve some packaging issues in the pipeline (again)
• Updated build.yml to output sf version to help with troubleshooting any future pipeline issues

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.5...v4.11.6

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZfGQAW
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZfGQAW
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfGQAW
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfGQAW

Added Custom Index for Log Retention Date

Core Unlocked Package Changes

Added Custom Index for Log__c.LogRetentionDate__c

• Added a custom index for the field Log__c.LogRetentionDate__c. This should help speed up the LogBatchPurger batch job (among other things that use this field, such as list views, etc.) in orgs with large data volumes (LDV).

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.4...v4.11.5

• SFDX CLI: sfdx package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZdZQAW
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdZQAW
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdZQAW

Removed Chatter dependencies

For years, Nebula Logger has leveraged Chatter's field feed tracking functionality to automatically create Chatter posts for new Log__c and LogEntry__c records. In Salesforce, this can be done in 2 steps:

1. Enabling feeds on a custom object, like Log__c
2. Enabling feed tracking on a field within that object, such as Log__c.LoggedBy__c

When deploying metadata/installing packages, Salesforce will gracefully handle orgs with Chatter disabled:

• When Chatter is enabled in the org, the trackFeedHistory node in field metadata is used to automatically enable Chatter's feed tracking in the appropriate fields
• When Chatter is disabled in the org, the fields still deploy & the trackFeedHistory node is ignored/the deployment completes successfully

However, several of the App Builder pages (FlexiPage metadata) in Nebula Logger have been using the standard Chatter components to display the record's Chatter activity. Using these standard components has created a hard dependency on having Chatter enabled - orgs with Chatter disabled have been blocked from installing Nebula Logger.

Given that Nebula Logger's usage of Chatter is very simple (it only has field feed tracking enabled as a convenience - there is no other functionality in Nebula Logger that relies on Chatter), having Chatter disabled should not prevent orgs from utilizing Nebula Logger. As a compromise, this release removes the Chatter components from Nebula Logger's UI, but feed data is still automatically tracked on the backend in orgs that have Chatter enabled.

Core Unlocked Package Changes

Removed Chatter dependencies

• Disabled Chatter in base scratch org file config/scratch-orgs/base-scratch-def.json to help implicitly test in the pipeline that Chatter is not required to deploy/install Nebula Logger
  • The experience cloud scratch org file config/scratch-orgs/experience-cloud-scratch-def.json will continue to have Chatter enabled to help test that Chatter being enabled doesn't cause problems either 😅
• Removed all Chatter components in FlexiPage metadata to remove a dependency on Chatter being enabled in orgs - Chatter is no longer required 🥳
  • No changes have been made to the objects & fields that have Chatter feed tracking enabled (<trackFeedHistory>true</trackFeedHistory> in the field XML)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.3...v4.11.4

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZdPQAW
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZdPQAW
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdPQAW
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdPQAW

Bugfix for unhandled exception when email limits are reached

Many thanks to @patrick-skamarak for this release!

Core Unlocked Package Changes

Bugfixes

• @patrick-skamarak reported issue #547 and fixed it in PR #548 🥳 This was an issue in the Apex class LoggerEmailSender where it would continue to try (and fail) to send email notifications when the org's daily limit for SingleEmail had been exceeded. Now, it will just skip attempting to send email notifications when the limit has been exceeded.
  • There is a related open issue, #369, to improve how emails are sent to prevent (or drastically reduce) the usage of the SingleEmail limits. This will hopefully be implemented in the coming weeks as part of the v4.12.0 milestone (Winter '24 release.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.2...v4.11.3

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZd0QAG
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZd0QAG
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZd0QAG
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZd0QAG

New Logger.exception() methods for Apex developers

Core Unlocked Package Changes

New Logger.exception() methods for Apex developers

This release provides some syntactic sugar for Apex developers when logging exceptions. A common pattern for using Nebula Logger is to log exceptions in try-catch blocks. Once an exception has been caught, Apex developers have to add 3 lines of code in order to log the exception & re-throw it, as shown below:

try {
    insert new Account();
} catch (System.Exception ex) {
    Logger.error('something broke 😥', ex);
    Logger.saveLog(Logger.SaveMethod.EVENT_BUS);
    throw ex;
}

Although 3 lines of code isn't a huge amount of code, it's still tedious to have to repeat the same code in any relevant try-catch blocks. Now, Apex developers can use the new method overloads Logger.exception() to consolidate down to 1 line in a catch block. The end result of the below snippet is identical to the snippet above - both result in a new ERROR log entry being generated, automatically saved, and then the exception is thrown.

try {
    insert new Account();
} catch (System.Exception ex) {
    Logger.exception('something broke 😥', ex);
}

The full list of new Logger.exception() method overloads is shown below. Each of the methods will log an entry with ERROR logging level, save the log, and then throw the provided exception. Since an exception is always thrown, the method overloads all have a void return type.

global static void exception(LogMessage logMessage, System.Exception apexException);
global static void exception(LogMessage logMessage, Id recordId, System.Exception apexException);
global static void exception(LogMessage logMessage, SObject record, System.Exception apexException);
global static void exception(LogMessage logMessage, List<SObject> records, System.Exception apexException);
global static void exception(String message, System.Exception apexException);
global static void exception(String message, Id recordId, System.Exception apexException);
global static void exception(String message, SObject record, System.Exception apexException);
global static void exception(String message, List<SObject> records, System.Exception apexException);

Bugfixes

• Bugfix for issue #529 where the optional integration with api.status.salesforce.com would cause exceptions in Nebula Logger if the remote site setting was disabled and the callout was still enabled via LoggerParameter__mdt record CallStatusApi. Now, Nebula Logger internally catches any callout exceptions, which should prevent any downstream issues from occurring.

Apex Test Improvements

• Scope creep: finished a few TODO items in the Apex class Logger_Tests (part of the logger engine layer) so that it's not aware of the log-management layer by rewriting several test methods to remove references to Log__c and LogEntry__c. These tests now also use mocks for the System.EventBus class, so they're now much faster 🏎️

Pipeline Enhancements

• @JMercie closed issue #527 by updating Nebula Logger's pipeline & build scripts to use the new sf CLI, instead of the sfdx cli` (PR #532). Thanks to @JMercie for another amazing contribution! 🥳

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.1...v4.11.2

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001TsZAQA0
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001TsZAQA0
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsZAQA0
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsZAQA0

Added the Ability to Throw Fault Exception in Flow Actions

A huge thank you to @JMercie for working on this release, and congratulations on their first-ever open source contribution! (PR #516). And many thanks also to @Sidle for suggesting this great enhancement (issue #489).

Core Unlocked Package Changes

Added the Ability to Throw Fault Exceptions in Flow Actions

This release closes #489 by providing a new option when logging in Flow - when logging a Flow fault message (shown as 1 in the screenshot below), you can now have the invocable action automatically re-throw the encountered exception (shown as 2 in the screenshot below). This provides a great way to still display an error to the user & rollback any other DML in the current transaction, while still saving your logging data.

• Updated all 3 Flow invocable logging actions (Apex classes FlowLogEntry, FlowRecordLogEntry, and FlowCollectionLogEntry) to have a new optional Boolean property, shouldThrowFaultMessageException. When set to true, the provided Flow fault message (using the String property faultMessage) will be used to create & throw an instance of the standard exception class System.FlowException
• Updated FlowLogger to handle throwing the exception for all 3 Flow invocable logging actions

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.0...v4.11.1

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001TsX4QAK
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001TsX4QAK
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsX4QAK
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsX4QAK

v4.11.0 - Summer '23 Release

Managed Package Release - v4.11.0

This release is for both the unlocked package (as always), as well as the managed package! You can see everything that's changed between v4.10.0 and v4.11.0 by reviewing:

• The v4.11.0 milestone to see all of the issues & pull requests that are included in the this release.
• The diff between v4.10.0 and v4.11.0 to see all of the code & metadata changes that have been committed since the last managed package release.

⚠️ For orgs that are upgrading to this version of the managed package: two details to be aware of:

1. The enhancement from is purposefully being excluded from the managed package for this release. Release v4.10.5 added a custom index to the field LogEntry__c.OriginLocation__c to help optimize anything that filters on this field, such as SOQL queries, list views, reports, etc. This was implemented using the recently-added metadata type CustomIndex, which is considered generally-available (GA). However, there have been a handful of related errors reported due to the CustomIndex metadata, so it's being excluded from the managed package this release as a precaution to avoid any related upgrade issues.
2. There are some recent label changes to some existing metadata - most notably, the new lightning app "Logger Console" has been relabeled to "Nebula Logger". This change will not be automatically applied to orgs that are upgrading - you will continue to see the lightning app labeled as "Logger Console" in your org. It is completely your choice if you would like to keep the existing label, or manually relabel it in your org. If you would like to relabel it in your org, you can edit it under Setup --> App Manager --> edit the Logger Console app.

Core Unlocked Package Changes - v4.11.0

Metadata API Version Updated to v58.0

• Updated all metadata to API v58.0 (Summer '23 release)
• Updated some picklist values to have options for API v58.0 and 59.0
• Simplified some Apex calls to String.join() to remove extra conversions of Set<String> to List<String> - Summer '23 now supports iterating over Set<Object>
• Retrieved the metadata for fields & objects so the repo's version more closely matches the XML returned by the platform

logEntryEventStream LWC Enhancements

Currently, the LWC logEntryEventStream uses the emp API to subscribe/display the stream of LogEntryEvent__e platform events, which counts towards your org's daily limit for platform event delivery allocation (the docs for Platform Event Allocations has more details on this limit).

To help mitigate the usage of the org daily limit for platform event daily delivery allocations, this release includes 2 related changes:

• Added new control "Max Number of Events to Stream" (shown as #1 in the screenshot below) to set the max number of events to deliver to the LWC before the component auto-pauses the stream. A counter of the total number of events streamed for your session has also been added (shown as #2 in the screenshot below), as well as a <lightning-progress-ring> to show the percentage of events to stream before the component auto-pauses itself (shown as #3 in the screenshot below)

  

• Resolved #488 by adding new LoggerParameter__mdt record EnableLogEntryEventStream - when set to false, the entire component is completely disabled for the entire organization. The buttons on the LWC are hidden, input elements are disabled, and a warning message is displayed:

  

loggerHomeHeader LWC Enhancements

• Added plugin information to the header component in 2 places:

  • Added a count of enabled plugins directly below the lightning card's title. This only displays when 1 or more plugins are enabled in your org (not available in the managed package)

    

  • Added a comma-separated list of enabled plugins to 'Environment Details' button modal. This only displays when 1 or more plugins are enabled in your org (not available in the managed package)

    

LoggerHomePage FlexiPage Changes

• Updated the LoggerAdmin dashboard component on the LoggerHomePage FlexiPage to not hide the dashboard on error (controlled by updating the componentInstanceProperties attribute hideOnError to false - shown in App Builder with MS Paint's amazing ⚡ shape in the screenshot below). Previously, if the dashboard had any errors (such as permission issues with the running user), the home page just displayed an unhelpful empty space in place of the dashboard, making it hard to tell if the page had loaded properly or if the dashboard had an error. Now, the dashboard will display either way.

  

LoggerAdmin Dashboard Changes

• Removed the XML node <runningUser>[email protected]</runningUser> in LoggerAdmin.dashboard-meta.xml that caused problems for orgs that deploy the metadata (instead of using the unlocked or managed packages)
  • This value was from a scratch org used for building the dashboard, and including it in the metadata worked fine when deploying to other scratch orgs & when creating/installing package versions (even though that particular username would not exist in other orgs). However, when deploying Nebula Logger's metadata to production orgs, the deployment would fail due to not being able to find the matching user. Removing the XML node entirely avoids the deployment issue altogether, and seems cleaner than storing a random scratch org username inside of git

More Label Changes

• Updated the labels for several metadata items to start with "Nebula Logger" (instead of just "Logger") for clarity on what metadata is part of Nebula Logger - this is especially helpful in orgs that deploy the metadata (instead of using the unlocked or managed packages). The changed metadata includes:
  • AnimationRule
  • CustomPermission
  • FlexiPage
  • GlobalValueSet
  • LWCs
  • Permission Sets
  • Visualforce page

Updated Permission Sets

• Small bugfix from v4.10.6 release - updated the LoggerAdmin & LoggerLogViewer permission sets to add missing Apex class access to LoggerHomeHeaderController

README.md, Pipeline & Release Notes Changes

• Updated README.md to include the package installation command for the SF CLI (in addition to the SFDX CLI)
• Updated README.md to use the "classic" commands for SFDX CLI to better support people that are still using older versions of the SFDX CLI
• Updated the pipeline's pwsh script so it automatically update the package version ID in README.md for the new SF CLI command
• Updated release notes to start including the SF CLI command (see below!)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.10.6...v4.11.0

• SF CLI: sf package install --wait 30 --security-type AdminsOnly --package 04t5Y0000023SI6QAM
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000023SI6QAM
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000023SI6QAM
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000023SI6QAM

Core Managed Package - Nebula namespace

Full Changelog: v4.9.0...v4.10.0

• SF CLI: sf package install --wait 30 --security-type AdminsOnly --package 04t5Y0000023SI1QAM
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000023SI1QAM
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000023SI1QAM
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000023SI1QAM

Added More Fields on LogEntryEvent__e, Log__c, and LogEntry__c

This release is focused on automatically capturing & storing some new data points (in a few different areas) that provide additional context for monitoring & reporting.

Core Unlocked Package Changes

Logging in Lightning Components: New "Browser Details" fields on LogEntry__c

• Resolved #225 by updating the logger LWC (logEntryBuilder.js mostly) to capture details about the user's browser & screen. These details are automatically now stored in these new fields on LogEntryEvent__e and LogEntry__c:

  New Fields	Source of Data
  LogEntryEvent__e.BrowserFormFactor__c and LogEntry__c.BrowserFormFactor__c	The value of FORM_FACTOR, imported using import FORM_FACTOR from '@salesforce/client/formFactor';
  LogEntryEvent__e.BrowserLanguage__c and LogEntry__c.BrowserLanguage__c	The value of window.navigator.language
  LogEntryEvent__e.BrowserScreenResolution__c and LogEntry__c.BrowserScreenResolution__c	The value of window.screen.availWidth + ' x ' + window.screen.availHeight
  LogEntryEvent__e.BrowserUrl__c and LogEntry__c.BrowserUrl__c	The value of window.location.href
  LogEntryEvent__e.BrowserUserAgent__c and LogEntry__c.BrowserUserAgent__c	The value of window.navigator.userAgent
  LogEntryEvent__e.BrowserWindowResolution__c and LogEntry__c.BrowserWindowResolution__c	The value of window.innerWidth + ' x ' + window.innerHeight

Logging in Flow: New Flow Metadata fields on LogEntry__c

• Resolved #451 by capturing some additional details about the running Flow via the object FlowDefinitionView. These details are automatically now stored in these new fields:

  New Fields	Source of Data
  LogEntry__c.FlowRecordTriggerType__c	The value of FlowDefinitionView.RecordTriggerType
  LogEntry__c.FlowTriggerOrder__c	The value of FlowDefinitionView.TriggerOrder
  LogEntry__c.FlowTriggerSObjectType__c	The value of FlowDefinitionView.TriggerObjectOrEvent.QualifiedApiName

Organization Details: New & Deprecated fields on LogEntryEvent__e and Log__c

• "Renamed" (by creating new fields) some fields on LogEntryEvent__e and Log__c to have a more consistent naming convention. Note that the old fields are still included in the core package and are still populated so that orgs have time to update any existing reporting, etc. Eventually, the old fields will be fully removed from the package.

  Field Change	Source of Data
  Deprecated Log__c.ApiReleaseNumber__c and replaced it with Log__c.OrganizationReleaseNumber__c	Retrieved via the optional callout to https://api.status.salesforce.com
  Deprecated Log__c.ApiReleaseVersion__c and replaced it with Log__c.OrganizationReleaseVersion__c	Retrieved via the optional callout to https://api.status.salesforce.com
  Deprecated LogEntryEvent__e.ApiVersion__c and Log__c.ApiVersion__c and replaced them with LogEntryEvent__e.OrganizationApiVersion__c and Log__c.OrganizationApiVersion__c	The value of Logger.getOrganizationVersion()
  Added new field Log__c.OrganizationLocation__c	Retrieved via the optional callout to https://api.status.salesforce.com

Logger Engine Changes

• Made some internal changes to the logger LWC so that the JavaScript code's approach more closely aligns with the Apex code's approach. This should not have any functional changes (hopefully 😅), this is just to try to provide a little more consistency within the codebase for approaching the same goal (logging) in 2 different languages (Apex & JavaScript).

  Item	In Apex	In JavaScript
  Object used to store in-memory logging data	LogEntryEvent__e object	ComponentLogEntry inner class in logEntryBuilder.js
  Internal method used to access/update in-memory logging data	Instance method LogEntryEventBuilder.getLogEntryEvent()	Instance method LogEntryEventBuilder.getComponentLogEntry() in logEntryBuilder.js

Bugfixes

• Small bugfix for logging in Flow: Added an extra guard clause in the private instance method LogEntryHandler.setFlowDefinitionFields() to prevent a possible NullPointerException. Previously, the code assumed that when OriginLocation__c == 'Flow', then OriginLocation__c would be the API name of the logging Flow. However, this may not always be the case, especially since the invocable actions currently rely on admins/devs to provide the Flow's API name, which is inherently an imperfect approach - but there isn't currently a way in Apex or Flow to automatically determine the Flow's API name, so the new guard clause helps avoid an exception.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.10.5...v4.10.6

• SFDX CLI: sfdx package install --wait 20 --security-type AdminsOnly --package 04t5Y0000023SCqQAM
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000023SCqQAM
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000023SCqQAM