Bugfix: overzealous data masking rule for US social security numbers

Core Unlocked Package Changes

🐞 Fixed #542 (almost exactly 1 year after it was opened😅) to use a more targeted regular expression for identifying US social security numbers (SSN) to mask. Previously, the rule was not restrictive enough in the regular expression used in SensitiveDataRegEx__c, which resulted in the rule masking some values that it should have ignored.

For example, logging a message containing a (fake) credit card number like Here is a value 5000-1111-2222-0005 and it looks like a Mastercard number, so apply the Mastercard masking rule...

• Previously, this would unintentionally have applied the SSN rule instead, resulting in the value being masked as...
  • Here is a value XXX-XX-1111-2222-0005 and it looks like a Mastercard number, so apply the Mastercard masking rule
• Now, the US SSN has been corrected, and false-positive matches like credit card numbers will either be correctly masked (using their own matching credit card rule), or ignored (if not a valid SSN or credit card)
  • Here is a value ****-****-****-0005 and it looks like a Mastercard number, so apply the Mastercard masking rule

🤏 And a little bit of scope creep included:

• Made a small optimization in the Apex class ComponentLogger to cache the field map for LogEntryEvent__e once per transaction
  • This map is used internally to validate & set custom fields in JavaScript, which was added in release v4.14.6
  • Previously, ComponentLogger would re-call the describe method for LogEntryEvent__e every time there was a component log entry that was setting 1 or more custom fields

Pipeline Changes

• Updated pipeline script scripts/build/validate-custom-metadata-records.apex to validate that the regex values in LogEntryDataMaskRule__mdt work as expected

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.6...v4.14.7

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

Custom Field Mappings Support for Lightning Components

Core Unlocked Package Changes

Resolved #718 by adding the ability to set custom fields on a log entry in JavaScript (lightning components), using a new function setField() in logEntryBuilder.js. This is the JavaScript equivalent to the Apex method overloads setField() in LogEntryEventBuilder.cls that were introduced in release v4.13.14.

• To use the new setField() function, pass an object as the function's single parameter. The object should contain the custom fields on LogEntryEvent__e that you want to set, along with their corresponding values. For example: { SomeField__c": "some value", "AnotherField__c": "another value" }

  import { createLogger } from "c/logger";
  
  export default class LoggerCustomFieldDemo extends LightningElement {
    logger;
  
    async connectedCallback() {
      this.logger = await createLogger();
  
      this.logger.info("Hello, world! This log entry has 2 custom fields set.")
        .setField({
          SomeCustomTextField__c: "some text value",
          SomeCustomNumberField__c: 123,
        });
  
      this.logger.debug("Hello again, world! This log entry has 1 other custom field set.")
        .setField({
          AnotherCustomTextField__c: "another text value",
        });
  
      this.logger.saveLog();
    }
  }

Note

The code above only highlights the new functionality that is now available when logging in lightning components. For more info on how to fully set up custom field mappings, see this section in README.md.

Recipes Metadata Changes

• Updated the demo lighting components in the recipes metadata folder to set a custom field on LogEntry__c. This provides a quick & easy way to verify that the functionality works for lightning components.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.5...v4.14.6

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

Added loggerSettings LWC to utility bar

Core Unlocked Package Changes

Added the Logger Settings component to the Logger Console app's utility bar, which makes it much easier to access. This component is still available on the app's homepage, as well as via a custom tab - but those locations aren't always convenient if you are trying to view existing logging data + quickly adjust settings. Accessing it via the utility bar can be done at any point in the console app.

• Updated loggerSettings LWC to support the target lightning__UtilityBar (in addition to the 2 targets it previously had, lightning__HomePage and lightning__Tab)
• Added loggerSettings LWC to the flexipage LoggerConsoleUtilityBar
• Updated lightning-datatable in loggerSettings LWC to have the property wrap-table-header, which helps make the column headers more readable when shown in the utility bar

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.4...v4.14.5

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

Optionally Auto-Call lightning-logger LWC

Core Unlocked Package Changes

Resolved #702 by adding the optional ability to automatically call Salesforce's lightning-logger LWC when logging via lightning components. This then creates a "Lightning Logger" event in Event Monitoring. These events & the lightning-logger LWC were made generally available (GA) in Salesforce's Spring '24 release.

Important Note: for this new feature to work...

1. Event Monitoring is required & must be enabled in your org
2. The "Lightning Logger" events must be enabled for your org within Event Monitoring's settings
3. Nebula Logger's configuration will need to be updated in your org to enable it either org-wide or for specific users (details below)

Another Important Note: for orgs without Event Monitoring (or with Event Monitoring disabled), essentially nothing will actually happen when this feature is enabled in Nebula Logger in your orgs. It's a fully optional feature specifically for orgs that do have Event Monitoring.

For orgs with Event Monitoring setup:

• To enable this in Nebula Logger org-wide, or for a particular profile/user, set the new settings field LoggerSettings__c.IsJavaScriptLightningLoggerEnabled__c to true (default is false)

  

• To enable this in Nebula Logger for a particular scenario (using scenario-based logging), set the new scenario rule field LoggerScenarioRule__mdt.IsJavaScriptLightningLoggerEnabled__c to true (default is null)

  

• Once lightning-logger has been enabled in Nebula Logger, the JavaScript representation of Nebula Logger's log entry will be logged using lightning-logger. From there, Salesforce will do 2 things:

  1. New lightning-logger console statements will automatically be added your browser's console (just after Nebula Logger's own console statements).

     

  2. New "Lightning Logger" events will automatically be added in Event Monitoring. You can view these events under Setup → Event Monitoring → Event Log File Browser

     

A few small scope creep items that are also included:

• Finished some code cleanup leftover from v4.13.15 in logEntryBuilder.js and ComponentLogger.cls
  • Now browser details are internally represented as an object in both JS and Apex, and some old deprecated properties have been removed
  • Also added some extra jest tests to validate that the browser details are being properly set
• Fixed a small bug in a Logger where a System.debug() statement for scenario-based logging was using the wrong variable
• Updated LoggerLogCreator permission set to remove unnecessary access to the Apex class FlowLogger

Dev/Pipeline Changes

• Added a new bash script to automate setting up a new dev scratch org

• Upgraded to v4 of the codecov action in build.yml

• Upgraded to sf rc v2.56.6 to use the new --concise flag on sf apex test run

• Removed an old/duplicate Experience Cloud site that was used by the pipeline

• Added Apex class access to 2 Experience Cloud Guest User profiles to simplify manual testing efforts

• Created additional scratch def files & added them to build.yml - each one corresponds to a specific Salesforce feature that's optionally used by Nebula Logger, including a new one for Event Monitoring, to test the usage of lighting-logger. The pipeline only creates 2 at a time to avoid the dev hub's limit for active scratch orgs.

  1. Base scratch org. This is an existing scratch def used by the pipeline. All optional features are disabled in this scratch org.
  2. Event Monitoring scratch org. This is used to test the new integration with the LWC lightning-logger, which stores data in Event Monitoring.
  3. Experience Cloud scratch org. This is an existing scratch def used by the pipeline to validate functionality when an Experience Cloud site has been setup in an org.
  4. Platform Cache scratch org. This is used to test optionally using Platform Cache to cache some of Nebula Logger's SOQL queries to improve performance. Previously, the Experience Cloud scratch org (above) was also used to test platform cache, but now there is a standalone scratch def just for testing platform cache (and the Experience Cloud scratch org no longer has platform cache enabled).

  

  

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.3...v4.14.4

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

Bugfix: Incorrect LogEntryRecordPage Tab Visibility Rules

Core Unlocked Package Changes

• Small bugfix related to component visibility rules added in release v4.14.0, which prevented the tab "Related Record Details" from showing on LogEntryRecordPage.flexipage-meta.xml
• Also fixed some flaky tests in LogBatchPurgeController_Tests that caused (inconsistent) pipeline errors due to (sometimes) duplicate external ID values (occasionally)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.2...v4.14.3

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

Bugfix: Jest test failures not surfaced in pipeline

Core Unlocked Package Changes

• Switched back to using sfdx-lwc-jest for running jest tests - using sf force lightning lwc test run returns 0 exit code for failures, so failures weren't being surfaced
  • @jamessimone has opened issue #2991 in the CLI's repo for this issue
  • Also upgraded several dependencies in package.json
• Fixed some failing Jest tests for logger LWC - these were primarily failing due to some asserts being out of date due to the changes made in release v4.13.17

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.1...v4.14.2

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

Updated .prettierrc to use '"tabWidth": 2'

Core Unlocked Package Changes

Resolved #723 by switching to 2 spaces instead of 4 for all files in the repo - this shouldn't have any functional changes to Nebula Logger (hopefully 😅 )

• Added *.xml to .prettierignore and updated .prettierrc to remove formatting of XML files. Now XML metadata files will be committed using the exact format returned by Salesforce.
• Updated .prettierrc to use "tabWidth": 2 (instead of 4)
• Reformatted all files in the repo

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.14.0...v4.14.1

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

v4.14.0 - Summer '24 Release

Managed Package Release - v4.14.0

Happy late Summer '24 release! 🥳😎☀️ It's still technically summer, even if the Winter '25 release is quickly approaching 😅

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.13.0 and v4.14.0 by reviewing:

• The v4.14.0 milestone to see all of the issues & pull requests that are included in the this release.
• The diff between v4.13.0 and v4.14.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: There are several notable changes for this release, including...

• ✅ This release now provides a ton of new features (these features have been available in the unlocked package for a few months, but are new for the managed package):

  • Release v4.13.1 - ❤️ Apex observability enhancments 😍. Nebula Logger now automatically logs a snippet of your Apex code, providing a snapshot of the relevant codeblock. These snippets are displayed in a very fancy code-viewer on the LogEntry__c page, using PrismJS

    • This release also introduced several new fields on LogEntryEvent__e and LogEntry__c to streamline & simplify reporting on the metadata that generated each log entry

    

  • Release v4.13.2 - org limits are now automatically stored on every Log__c record, using the info returned by the class System.OrgLimits

    • • It also introduced a new LoggerParameter__mdt record, StoreOrganizationLimits, that can be used to disable capturing org limits data. By default, it's enabled (true)

    

  • Release v4.13.3 - Optionally enforce scenario-based logging usage, for teams that want to always require scenario-based logging to be used.

  • Release v4.13.5 - Several internal performance improvements were made to Nebula Logger's codebase (in the logger-engine layer/directory) to help reduce CPU time usage.

    • It also introduced a new LoggerParameter__mdt record, StoreHeapSizeLimit, that can be used to disable populating the fields LogEntryEvent__e.LimitsHeapSizeUsed__c and LogEntryEvent__c.LimitsHeapSizeUsed__c. This can help further improve performance for orgs that generate a lot of log entries in a single transaction, as calling the method System.Limits.getHeapSize() is a very CPU-intensive method call.

  • Release v4.13.14 - Custom field mappings support. This provides a way to easily extend Nebula Logger's data model by creating & populating your own custom fields on Nebula Logger's custom objects

    

• 🐞This release was delayed a few months so that some additional bugs could be fixed that impacted multiple orgs/companies using the managed package:

  • Release v4.13.15: Bugfix for the field LogEntryEvent__e.BrowserUrl__c not being long enough to store some URLs, which caused some logging data to fail to save
  • Release v4.13.16: Bugfixes for some issues related to scenario-based logging & the LoggerScenarioRule__mdt custom metadata type, which caused some logging data to fail to save
  • Release v4.13.7: Bugfixes for a lot of issues with JavaScript stack trace parsing, which caused inaccurate & incomplete data to be saved in fields like LogEntry__c.OriginLocation__c, LogEntry__c.OriginSourceApiName__c, LogEntry__c.OriginSourceActionName__c, etc. JavaScript stack trace parsing has been completely rewritten, and now uses stacktrace.js to handling parsing

Core Unlocked Package Changes - v4.14.0

This release is fairly small for the unlocked package, compared to the previous release of v4.13.17. However, this release is a milestone - it's the 100th package version of the unlocked package 💯 🥳 🪵 (The 100th release of Nebula Logger as a project was release v4.13.2, but the unlocked package wasn't created until release v4.4.1)

Summer '24 Release Upgrade

• Bumped all metadata to API v61.0 (Summer '24 release)
  • Also updated the list of picklist values in several 'API version' picklist fields
• Resolved #697 by updating LogEntryRecordPage and LogRecordPage flexipages to conditionally display tabs (tab-visibility functionality was added in Salesforce's Summer '24 release)
  • Also eliminated the tab "Database Result Details" on LogEntryRecordPage & consolidated its contents to instead be part of the tab "Related Records". This keeps all of the fields related to SObject data grouped together.

New LogEntry__c List Views

• Added 5 new list views on LogEntry__c

  1. All Exception Log Entries

  2. All HTTP Request Log Entries

  3. All HTTP Response Log Entries

  4. All REST Request Log Entries

  5. All REST Response Log Entries

     

Metadata & Code Cleanup

• Deprecated the formula field LogEntry__c.LoggingLevelWithImage__c, and reverted to only using LogEntry__c.LoggingLevel__c. The emojis shown in LoggingLevelWithImage__c have now been added to the labels of the picklist values in the global value set LoggingLevel.
  • By adding the emojis to the picklist values of LoggingLevel__c, it provides the same visual indicator as LoggingLevelWithImage__c, but LoggingLevel__c provides a meaningful sort order in list views, queries, etc. - sorting on LoggingLevelWithImage__c doesn't provide a very meaningful sort order.
  • ⚠️ Existing list views have been updated to use LoggingLevel__c, which will automatically be changed for orgs upgrading versions of the unlocked package. But for orgs using the managed package, the list views will not be automatically updated, you will need to manually update the list views' selected fields (if desired).
• Fixed #688 by updating LoggerSettingsController_Tests to call LogManagementDataSelector.getInstance().getUsersByNameSearch(), instead of duplicating the query
• Updated the descriptions of the 4 included permission sets to clarify what each one provides
• Code cleanup (internal use only): Updated public instance method LogEntryEventBuilder.setTimestamp() to use a fluent API, and streamlined the existing usages of setTimestamp() in several other classes by updating to use the fluent API

Pipeline & Dev Changes

• Fixed a flaky pipeline integration test in nebula-logger/extra-tests/tests/LogEntryEventHandler_Tests_FieldMappings.cls
• Added some sf CLI environment variables to build.yml to disable checking for updates during pipeline runs
  • The sf CLI is periodically upgraded in the repo, there's no need for the pipeline to check during every run
• Added new scratch org def file config/scratch-orgs/dev-scratch-def.json that will only be used for development (not in the pipeline or when creating package versions)
  • Also renamed the existing scratch def files to have a 'build-' prefix to clarify their purpose vs the (new) dev def file
• Added new path to sfdx-project.json for nebula-logger/dev/ to store some extra metadata that's used during dev. This metadata doesn't impact Nebula Logger directly & is not included in Nebula Logger's packages
  • This new path is now the default in sfdx-project.json for creating/retrieving new metadata

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.17...v4.14.0

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

Core Managed Package - Nebula namespace

Full Changelog: v4.13.0...v4.14.0

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

Overhauled JavaScript stack trace parsing

The changes in this release should not change anything about how you use Nebula Logger for JavaScript (JS) logging in lightning web components (LWCs) and Aura components - but the overall approach used internally by Nebula Logger for parsing JavaScript stack traces has been completely redesigned.

Previously, Apex code was used to parse JS stack traces (using the Apex classes LoggerStackTrace and ComponentLogger). But now, JS parsing occurs directly in JS, which provides several benefits:

• Bugfixes for several parsing issues: there have (apparently) been several problems in Nebula Logger for a year or two with parsing data from JS stack traces, due to factors like different browsers, how the logger LWC is leveraged, and in which of the available targets is used for your own LWCs/Aura components (which then call the logger LWC). This release should fix most of these issues.
• Code reuse & easier maintenance for Nebula Logger: the open source library JavaScript library stacktrace.js is now used to handle the majority of JS stack trace parsing, instead of trying to write code from scratch to handle parsing.
• Improved console logging statements in the browser's console: with a parsed version of the JS stack trace now available directly in JS, the logger LWC can now provide better context to JS developers trying to see the output of console statements when troubleshooting & debugging LWCs and Aura components.

Many thanks to @ZackFra for identifying the critical problems in the previous code & some approaches to use to resolve them (see PR #692). These contributions have led to identifying even more issues with the old approach that were previously unreported, and helped solidify the decision to migrate from Apex to JS for parsing JS stack traces.

And thanks to @jamessimone as well for all of his helping with questions & thoughts during the dev work, input on improving console logging statements, and code reviewing PR #692.

For a more details about the issues found & what's changed, see:

• Issue #691 - originally reported by @ZackFra, and includes the results of some of the issues found due to different browsers + different Salesforce contexts
• PR #692 - initial changes from @ZackFra to fix some issues, using the old Apex-based approach
• PR #727 - the changes merged for this release, which incorporates some concepts & changes from @ZackFra, but pivots from Apex to JS for parsing
• Issue #728 - this is one known issue that is not solved by this release. This will hopefully be addressed in a future release.

Core Unlocked Package Changes

• Fixed #691 by updating the logger LWC to leverage the open source library JavaScript library stacktrace.js to parse stack traces
  • Eliminated all of the Apex code in LoggerStackTrace and ComponentLogger that previously handled JS stack traces. There are still a few lingering items (enums, method overloads, etc.) that are now deprecated & will be removed in a future release
  • Added new js file loggerStackTrace.js to the logger LWC - the file contains a modified version of the parsing code from stacktrace.js, as well as a few additional pieces of logic to improve parsing of Salesforce-specific stack traces
• Improved the output of console logging statements. Each JS logging statement now includes a pretty-printed JSON string that has the most relevant info about the log entry's origin, including the timestamp of the log entry, the component name, function name, and the component metadata type

  • Console output in Chrome:

    

  • Console output in Firefox:

    

  • Console output in Microsoft Edge:

    

Recipes Metadata Changes

It took a lot of effort to even be able to test some of these issues, as Nebula Logger's repo previously didn't have sample metadata setup for most of the targets available for lightning components. This release includes several changes to make it easier to test logging in different targets in a scratch org, using multiple browsers. These changes are not included in Nebula Logger directly, but they help during development & testing. The changes include:

• Improving existing recipes metadata so that the 3 demo components (listed below) can now be easily tested in multiple contexts, using the Logger Recipes app
  • <c:loggerAuraEmbedDemo> Aura component
  • <c-loggerLWCEmbedDemo> LWC
  • <c-loggerLWCImportDemo> LWC
• Improving the Experience Cloud metadata stored in config (used by the pipeline & during development)
  • New(er) Lightning Web Runtime (LWR): Rebuilt the current Experience Cloud site to embed the recipes demo components in some pages to make them easy to test
  • Old Aura Framework: Created a second Experience Cloud site, using the older Aura framework template. This site makes it easy to test the same recipes demo components, using the older runtime, to ensure JS stack trace parsing works correctly

Now, the recipes app is setup to quickly test the 3 demo components in multiple targets

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.16...v4.13.17

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

Bugfixes for Scenario Rules

Core Unlocked Package Changes

• Fixed #538 by changing LogEntryEventHandler to always save LogEntryEvent__e records when LoggerSettings__c.DefaultPlatformEventStorageLoggingLevel__c is null. Thanks to @arbokrad for reporting this issue (and patience, as it's taken about a year to get this fixed 🙃 )
  • When previously using the user's logging level from LoggerSettings__c.LoggingLevel__c as a fallback value, it could result in entries being lost if a matching LoggerScenarioRule__mdt exists with a lower logging level
• Fixed some unreported issues in Logger with setScenario(String) and endScenario(String) not properly updating the field values returned by getUserSettings()
  • Now, both setScenario(String) and endScenario(String) wipe out & reload the in-memory instance of LoggerSettings__c (before applying any matching LoggerScenarioRule__mdt records) to ensure that there are not any remnants lingering when multiple LoggerScenarioRule__mdt records have been applied to the user's settings in a single transaction

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.15...v4.13.16

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