Plugin framework v2 + new Big Object Archive plugin + new Log Retention Rules plugin

Core Package Changes

This release of the core unlocked package is primarily focused on improving how plugins can interact with the core package - while working towards that goal, several enhancements & bugfixes have been included this release

• Replaced the checkbox field LoggerSettings__c.IsPlatformEventStorageEnabled__c with a new text field LoggerSettings__c.DefaultPlatformEventStorageLocation__c, providing a way for plugins (big object plugin in particular - see below) to provide additional storage location.

  • ⚠️ For orgs that are upgrading to this version: You will need to review & update your org's settings to configure the new field LoggerSettings__c.DefaultPlatformEventStorageLocation__c - if you previously had LoggerSettings__c.IsPlatformEventStorageEnabled__c set to true, then you should update LoggerSettings__c.DefaultPlatformEventStorageLocation__c to be set to CUSTOM_OBJECTS. This is the default value going forward, and can be updated using the "Logger Settings" tab available in the Logger Console app (see screenshot below)

    

• Added new picklist field Log__c.LogPurgeAction__c - out of the box, only the value 'Delete' is included/used, but plugins (like the Big Object plugin below) can add new picklist values to support new actions.

• Fixed an issue in LogEntryEventBuilder where some stack trace lines would be duplicated

• Renamed class LoggerEmailUtils to LoggerEmailSender

• Added additional fixes for #276 that was partially fixed in v4.7.0 - some of the unit tests had not been updated to check if deliverability was enabled, resulting in tests still failing in orgs with deliverability disabled. Thanks to @gjslagle12 for reporting these test failures!

• Added new public method LogBatchPurger.setChainedBatchSize(Integer) that's used internally to ensure any chained batch jobs use the same batch size as the original job. Previously, only the first job would use the specified batch size, and any chained jobs then used the default of 200.

• Started adding data classifications to custom fields throughout the data model to start progress on #292

• New fields DatabaseResultCollectionSize__c and RecordCollectionSize__c (originally planned as part of #222)

• Partially implemented #240 by adding new methods LogEntryEventBuilder.setHttpRequestDetails(request) and LogEntryEventBuilder.setHttpResponseDetails(response), which populates new fields on LogEntryEvent__e and LogEntry__c. In a future release, I am going to consider also adding overloads to the logging methods in Logger. The new fields on LogEntryEvent__e and LogEntry__c are:

  • HttpRequestBody__c
  • HttpRequestBodyMasked__c
  • HttpRequestCompressed__c
  • HttpRequestEndpoint__c
  • HttpRequestMethod__c
  • HttpResponseBody__c
  • HttpResponseBodyMasked__c
  • HttpResponseHeaderKeys__c
  • HttpResponseStatus__c
  • HttpResponseStatusCode__c

  

  

Version 2 of Plugin Framework

This release includes a new & improved approach for building plugins for Nebula Logger. The first plugin framework beta (referred to as plugin-v1-beta) was originally released last year in the v4.5.0 release of the unlocked package. Since then, it's remained largely unchanged, but there has been a lot of feedback in the last ~9 months. The new beta of the plugin framework (plugin-v2-beta) is a complete overhaul of how plugins are built for Nebula Logger, allowing much more control and functionality for plugins.

• Redesigned plugins for Nebula Logger's trigger handler framework, and added the ability to create plugins for the batch class LogBatchPurger. The old Apex class LoggerSObjectHandlerPlugin has been removed - Apex plugins can now be created by implementing one (or both) of the new interfaces:

  • LoggerPlugin.Batchable - this interface is used to define & run plugins within the batch job LogBatchPurger
  • LoggerPlugin.Triggerable - this interface is used to define & run plugins within Nebula Logger's trigger framework, LoggerSObjectHandler

• Reintroduced LoggerSObjectHandler__mdt custom metadata type. This can be used to enable/disable some of Nebula Logger's trigger handler classes, as well as a way to override the default trigger handlers with a custom one

  

New Plugin: Log Entry Archive Plugin

This new plugins provides archiving of logging data in a Big Object, allowing you to clear up data storage used by the custom objects (Log__c, LogEntry__c, and LogEntryTag__c) while still housing your logging data within your Salesforce org. A huge 'thank you' to @jamessimone for all of his work on this - he and I originally started work on this over a year ago, and it unfortunately was put on hold for several months while other technical debt & enhancements were first prioritized. It's incredible to finally see this being released!

ℹ️ This plugin is considered to be in beta. It has been tested & could be deployed to a production org, but due to some severe limitations with Big Objects, this is going to be considered in beta so that additional community feedback can be collected & any related changes can be implemented. In the meantime, upgrading to new versions of the Log Entry Archive plugin may involve some additional manual steps - if this becomes necessary for future upgrades, I'll include details in future releases for any manual steps needed. If/when you run into any issues with this in the future, feel free to start a discussion to ask for help!

• The Big Object LogEntryArchive__b contains all of the same fields (or comparable fields) as LogEntryEvent__e, Log__c, and LogEntry__c combined.

• Closes #117 - a huge thanks to @jamessimone for implementing this via PR #287 (and for creating Big Object prototypes last year!). The plugin provides 2 custom save methods that can be used to bypass platform events (LogEntryEvent__e) and custom objects (Log__c, LogEntry__c, and LogEntryTag__c) and instead use the Big Object LogEntryArchive__b as the primary storage location. This also closes #128 - implemented via PR #288, the plugin can also archive Log__c, LogEntry__c and LogEntryTag__c data before the batch job deletes any records where Log__c.LogPurgeAction__c == 'Archive'. This means that the plugin can be configured in 4 ways:

  1. LoggerSettings__c.DefaultSaveMethod__c = EVENT_BUS, LoggerSettings__c.DefaultPlatformEventStorageLocation__c = BIG_OBJECT - with these options, Nebula Logger will still leverage the Event Bus, which ensures that log entries are saved, even if an exception is thrown. This may not be ideal for all orgs/users due to org limits for platform events, but this would provide the most reliable way of logging directly to LogEntryArchive__b & circumvent the custom objects Log__c, LogEntry__c and LogEntryTag__c
  2. LoggerSettings__c.DefaultSaveMethod__c = BIG_OBJECT_IMMEDIATE - with this option, Nebula Logger will skip the Event Bus, and instead try to write directly to the Big Object LogEntryArchive__b. Any Big Object records that are saved will not be rolled back if there are any exceptions in the transaction - however, this option only works if you save the Big Objects before performing DML on any "normal" SObjects. If you perform DML on another SObject first, and then attempt to save directly to the Big Object, the platform will throw a mixed DML exception, and no Big Object records will be saved.
  3. LoggerSettings__c.DefaultSaveMethod__c = BIG_OBJECT_QUEUEABLE - with this option, Nebula Logger will asynchronously save Big Object records using a queueable job. This is helpful in avoiding hitting limits in the original transaction, and also avoids the mixed DML exception that can occur when using BIG_OBJECT_IMMEDIATE (above). However, if an exception occurs in the current transaction, then the queueable job will not be enqueued.
  4. LoggerSettings__c.DefaultSaveMethod__c = EVENT_BUS, LoggerSettings__c.DefaultPlatformEventStorageLocation__c = CUSTOM_OBJECTS, LoggerSettings__c.DefaultLogPurgeAction__c = 'Archive' - with these options configured, Nebula Logger will utilize the Event Bus to ensure any log entries are published (even if an exception occurs), and the data is then initially stored in the custom objects Log__c, LogEntry__c and LogEntryTag__c. Once the log's retention date has passed (Log__c.LogRetentionDate__c <= System.today(), then the plugin will archive the custom object data into LogEntryArchive__b before the custom object data is deleted.

• The included permission set LoggerLogEntryArchiveAdmin provides all of the permissions needed for LogEntryArchive__b and the included Log Entry Archives tab

• Includes a custom tab 'Log Entry Archives' to display the LWC logEntryArchives. This LWC provides a datatable view of LogEntryArchive__b data, with the ability to filter on Timestamp__c, LoggingLevel__c, and Message__c fields.

  

New Plugin: Log Retention Rules

This new plugin closes #226 by adding the ability to create & deploy advanced, configurable rules for setting the retention date of Log__c records, using custom metadata types `LogRetent...

v4.7.0 - Spring '22 Release

⚠️ For orgs that are upgrading to this version: you will need to review & update your org's configurations - 2 fields on the custom hierarchy settings object LoggerSettings__c have been added - IsSavingEnabled__c and IsPlatformEventStorageEnabled__c - that will prevent logs from being saved until you update the values. When deploying new checkbox (boolean) fields, Salesforce automatically sets the value to false, even if the field's default value has true specified. You can easily update these values using the tab "Logger Settings", available via the Logger Console app - it's recommended that both fields are set to true.

New Features for LoggerSettings__c

• Closed #258 by adding 2 new LoggerSettings__c fields to provide control over platform events & custom objects
  1. IsSavingEnabled__c - when disabled, any calls to Logger.saveLog() are ignored. This allows you to still use Logger for outputting Apex debug statements, but it completely disables saving/publishing of the platform event LogEntryEvent__e.
  2. IsPlatformEventStorageEnabled__c - this fields controls if LogEntryEvent__e platform events are transformed & stored in the custom objects Log__c and LogEntry__c (when IsSavingEnabled__c == true).
• Closed #279 by adding some new features for "log scenarios"
  • Configure a default scenario by setting the new field LoggerSettings__c.DefaultLogScenario__c
  • Retrieve the current transaction's scenario in Apex using new method Logger.getScenario()
• Added the ability to assign a default OwnerId for new Log__c records via a new settings field, LoggerSettings__c.DefaultLogOwner__c. This is useful for orgs that assign/manage logs for triage purposes (often done in production environments for managing logs with errors & warnings) and want more control over who is assigned as the log owner. The setting can be configured with 1 of 5 possible values
  1. Blank (null) - this will provide the same behavior that has existed in previous releases - the Log__c record will simply be assigned to the user that generated the log
  2. User ID
  3. Username
  4. Queue ID
  5. Queue DeveloperName
• Renamed LoggerSettings__c field StripInaccessibleRecordFields__c to IsRecordFieldStrippingEnabled__c for a consistent field naming convention
• Updated lwc loggerSettings and logEntryEventStream to support using a namespace when running in the managed package by introducing a new Apex class, LoggerSObjectMetadata. This class provides LWCs with info about SObject, SObjectField, and PicklistEntry metadata (including details about a namespace, when applicable).
• Bumped all metadata to API v54.0 (Spring '22 release)
• Added picklist values in Log__c.ApiVersion__c for all 3 API versions in calendar year 2022
• Closed #15 and closed #195 by expanding wiki content. Changes for the wiki are managed in a separate repo, so this PR doesn't contain the changes, but the wiki updates have been done in parallel

New Features for Log__c Quick Action "Open Viewer" (formerly "View JSON")

• Renamed the lwc logJSON back to logViewer. This change only impacts the unlocked package.
• Renamed the quick action "View JSON" (again) to "Open Viewer"
• Enhanced logViewer lwc to display tabs for both JSON (existing) and log file (new). The new 'log file' view displays the log's related log entries in a streamlined view that includes each entry's timestamp, logging level, message, and stack trace
• Added a new download button to logViewer to export the selected content to a file

Bugfixes

• Fixed #271 - Updated LoggerTestUtils to use the current user's profile in most cases, instead of trying to query for a particular profile. For testing behavior related to profiles without access to Logger, integration tests have been added to the extra-tests folder that still leverage the 'Standard User' profile in a scratch org, but these tests are not included in the package.
• Fixed #272 by explicitly declaring the list as List<Schema.PicklistEntry> instead of just List<PicklistEntry>
• Fixed #276 by updating LoggerEmailUtils to check if email deliverability is enabled in the current org prior to attempting to send any emails
• Wrapped all dynamic query strings in String.escapeSingleQuotes() as a security best practice & to avoid PMD reporting errors for ApexSOQLInjection

Pipeline / DevOps

• Updated pipeline to use JWT bearer flow + sfdx bot user for dev hub auth
• Updated the Experience Cloud scratch definition to use Spanish as the language/Spain as the country as another way to monitor/test for any language-related issues in the pipeline
• Cleaned up some PMD rule suppressions
• Added basic Experience Cloud site to the pipeline to provide a better method of testing Experience Cloud scenarios (the site is not included in the package itself - it's only used in the pipeline). Previously, the pipeline created an Experience Cloud site via the async function sfdx force:community:create + a 2 minute delay, but the async operation is inconsistent in how long it takes to complete. By deploying the site metadata in the pipeline, it becomes a synchronous operation, which should prevent some inconsistent pipeline failures.
• Updated/added some devDependencies in package.json to handle some dependabot alerts
• Closed #263 by adding "ancestorVersion": "HIGHEST" in the managed package's sfdx-project.json file

New Managed Package Release

• For orgs that are still using the managed package, this version contains all of the changes made between v4.6.0 and v4.7.0. Check out the v4.7.0 Milestone to see all of the new features & bugfixes

---

View v4.7.0 Milestone
View v4.7.0 Full Changelog from v4.6.0

UI Cleanup

• Replaced old logJSONViewer aura cmp & logViewer lwc with a new consolidated logJSON quickaction lwc - Nebula Logger is now officially aura-free.... aura can't hurt us anymore 😭
  • Due to a (frustrating) limitation with updating quickaction metadata, the old 'View JSON' quickaction on Log__c has been replaced with a new 'View Log JSON' quickaction, which shows the new logJSON lwc
• Updated layouts & objects to remove the tags <excludeButtons>IsotopeSubscription</excludeButtons> and <excludedStandardButtons>OpenListInQuip</excludedStandardButtons> because dealing with standard buttons is the worst. In orgs that don't have these features enabled, the package installation fails - thanks to systemsfixer on SFXD for reporting this!
• Fixed #264 - Optimized the LogEntry__c flexipage by moving limits fields to be within a tab, and removed some fields from the page
  • App builder's page analysis still says that the EPT could be improved, but I have not heard much feedback on page performance, so I don't want to go overboard with removing fields or drastically changing the layout
• Added the Chatter Feed component to the utility bar in the Logger Console app
• Added @jamessimone's pwsh function to auto-promote production package versions when changes are merged to the main branch

Small bugfixes & enhancements, improvements for deployments, directories, and docs

🐛 Bugfixes & Enhancements

• Fixed #253 - some tests would previously fail in orgs that also had a managed package (any managed package) installed that also contained a Logger class
• Fixed #256 - added additional guard clauses & null checks to prevent an exception that would occur when logging a null message string
• Fixed #257 - moved some test methods for LoggerSettingsController outside of the core package, and instead put them into the extra-tests folder. Since these tests rely on the 'Standard User' profile, they can fail in orgs that have installed the package for all users. They'll continue to run in the pipeline to ensure that everything is working as expected
• Shortened the label for the field LogEntry__c.TransactionEntryNumber__c to just "Entry #"
• Moved 'streaming/paused' toggle button in logEntryEventStream component to be in the top-right (next to the 'clear' button)

🏗️ Deployment enhancements for pipeline

• Rewrote pwsh script for creating & installing package versions to be more generic/reusable. This script will eventually also be used for creating & installing plugins. Thanks again to @jamessimone for his incredible help with getting this working! 🥳
• Added parallel job in pipeline to create a beta version of the managed package - this gives early feedback on any issues, even though the managed package will only have 3 releases/year. Some old, deprecated metadata was re-added under the managed-package folder since managed packages do not currently support deprecating (except via a pilot program)

📁 Directories cleaned up

• Consolidated all metadata to be under the nebula-logger top-level directory. Previously, metadata was spaced between several different top-level directories
• Moved several top-level config files to be within the config folder
• Renamed content folder to images
• Updated folder structure for Slack plugin to make it easier to consolidate with the core metadata - this is useful for orgs that want to deploy the unpackage metadata, instead of using the unlocked package

📜 Docs cleaned up

• Fixed some tpyos in ApexDoc comments
• Added some missing parameters in JSDoc comments

New 'Logger Settings' lwc/tab

⚠️ For orgs that are upgrading to this version: you may need to review & update your org's configurations - 3 fields on the custom hierarchy settings object LoggerSettings__c have been renamed in this release:

• AnonymousMode__c → IsAnonymousModeEnabled__c
• ApplyDataMaskRules__c → IsDataMaskingEnabled__c
• IsComponentConsoleLoggingEnabled__c → IsJavaScriptConsoleLoggingEnabled__c

New 'Logger Settings' lwc/tab

PR #254 introduces a new lwc, loggerSettings, as a tab in the Logger Console app. It provides several features for managing LoggerSettings__c records:

• Provides a datatable of all LoggerSettings__c records, along with functionality to view, create, edit and delete records. Anyone with access to the tab/lwc can see the datatable and the 'View' row action - but in order to access/use the 'New' button (create), and the 'Edit' & 'Delete' row actions, users must either have update access on the LoggerSettings__c object(LoggerSettings__c.SObjectType.getDescribe().isUpdateable()), or have the custom permission 'Can Modify Logger Settings' (FeatureManagement.checkPermission('CanModifyLoggerSettings')). This is useful for orgs where people may have the LoggerAdmin permission set, but aren't full System Admins.

  • The LoggerAdmin permission set has access to view, create, edit, and delete
  • The LoggerLogViewer permission set only has access to view
  • The LoggerLogCreator and LoggerEndUser permission sets do not have access to the tab/lwc

  

• Provides picklist-style inputs for fields that really should be picklists. Custom settings objects do not support several field types, including picklists - instead, text fields are used on the object, but this can lead to bad config data being entered (e.g., an admin/developer mistypes the name of a LoggingLevel or Logger.SaveMethod enum value. The lwc solves this by presenting these fields as picklists, using some Apex in the LoggerSettingsController class to generate the list of picklist options. This prevants any isssues with tpyos, and it simplifies the configuration process for admins/developers

  

• Bonus unexpected feature: using this component, you can now configure LoggerSettings__c for the the Automated Process user. When using the standard UI for custom settings, you cannot search for/select the Automated Process user, but it apparently works just fine when the settings record is created via Apex

  

Other LWC Changes

• Added icon on logEntryEventStream, fixed some issues with unresolved Promises in jest tests
• Improved jest tests for logViewer component

Documentation Enhancements

• Added JSDoc comments the 2 classes in the lwc logger.js: Logger and LogEntryBuilder. JSDoc comments have also been incorporated into the GitHub Pages site will now include these docs going forward (alongside the existing Apex docs)
• Cleaned up some ApexDoc comments in various classes for better clarity

Pipeline Enhancements

• Made the pipeline faster by adding caching in the pipeline for sfdx-cli
• Automated org type testing by updating the pipeline to deploy to 2 different scratch orgs (in parallel) to confirm the metadata works in 2 contexts:
  • A base scratch org - an Enterprise Edition org with Chatter enabled, and Experience Cloud disabled
  • An Experience Cloud scratch org - this is the same as the base org, but also has Experience Cloud enabled, with 1 site created
• pipeline uses 2 scratch orgs now to cover different scenarios

---

Thanks so much to @jamessimone for a ton of help on this release! 🥳

SaveMethod support in Flow & Lightning Components, RegEx filtering in logEntryEventStream component

Support for Specifying a SaveMethod in Flow Invocable Classes and Lightning Components

Logging for Flow and Lightning Components can now specify the name of an instance of Logger.SaveMethod to use when saving. This is conceptually the same feature that Apex developers can already use by calling Logger.saveLog(SaveMethod)

• All 3 Flow Log Entry invocable classes have a new optional property called 'Save Method' that can be used to specify the save method to use when 'Save Log' is true

  

• logger.js now accepts an optional parameter saveMethodName when calling saveLog()

  const logger = this.template.querySelector(LOGGER_NAME);
  logger.info('example of logging in LWC');
  logger.saveLog('QUEUEABLE'); // Supported options are: EVENT_BUS (default), QUEUEABLE, REST_API, and SYNCRONOUS_DML

• Added a function getUserSettings() to logger.js - this returns an instance of ComponentLogger.ComponentLoggerSettings. It is conceptually similar to the Apex method Logger.getUserSettings()

RegEx Filtering in logEntryEventStream Component

@jamessimone made some amazing enhancements to the 'Log Entry Event Stream' tab in #251

• Now, you can use regex for advanced criteria when filtering on LogEntryEvent__e records

• A filter for the new field LogEntryEvent__e.Scenario__c has also been included, providing yet another way to filter on LogEntryEvent__e records

  

Other Changes

• All metadata has been updated to API v53.0 (Winter '22 release)

New 'Log Scenario Rules' CMDT, New 'Logger Admin Dashboard' Plugin

New 'Log Scenario Rules' CMDT

This PR closes #235 (and further extends the 'scenario' functionality added in #218) - Added new CMDT object LoggerScenarioRule__mdt to provide a way to configure scenario-specific behavior. Each rule controls 2 aspects of a scenario:

1. The user's logging level for a particular scenario - This overrides the logging level configured via LoggerSettings__c.
2. The retention date for a particular scenario - This overrides the retention date configured via LoggerSettings__c.

Example rule

This example rule overrides the user's logging level for the scenario 'some scenario' - after Logger.setScenario(String) is called, the user will (temporarily) have their logging level set to FINE for the remainder of the Apex transaction. It also sets the retention date for the logs to 90 days.

With the above rule configured, this script will save only the second log entry (the one logged after calling Logger.setScenario(String), and the log will have a retention date of "TODAY + 90 days"

Logger.getUserSettings().LoggingLevel__c = LoggingLevel.ERROR.name();
Logger.info('this will not be saved since it does not meet the user logging level of ERROR');
Logger.setScenario('some scenario');
Logger.info('this will be saved since it meets the scenario logging level, and setScenario() has been called');
Logger.saveLog();

New 'Logger Admin Dashboard' Plugin

The previous release, v4.6.11, included a new dynamic dashboard. I did not take into consideration that most orgs have a limit of 10 dynamic dashboards, which has caused upgrade issues for several people . To help with this issue, the dashboard has been removed from the core unlocked package, and is now going to be provided as an optional plugin package - any org that wants to use the dashboard (and has not hit their org limit) can install the dashboard plugin on top of Nebula Logger v4.6.12. Check out the dashboard plugin's README for installation details.

Admin enhancements: new dashboard, reports, and error email alerts

New 'Logger Admin' dashboard + related reports + homepage

Closed #182 by adding several new metadata items:

• New 'Logger Admin' dashboard - this an initial attempt at providing a dashboard, but any feedback is welcome on how to further improve the dashboard
• New reports (used by the dashboard)
• New homepage for the Logger Console app that displays the 'Logger Admin' dashboard

New email alerts for Logger errors

Closed #229 by sending an email to the org's list of Apex Exception Email recipients (configured under Setup --> Email --> Apex Exception Email) any time an error occurs in Logger.

• This is being introduced primarily to help with troubleshooting any issues when saving LogEntryEvent__e records via the EventBus.publish() method, several other DML statements (for Log__c, LogEntry__c, etc.) have also been updated to send email alerts for any DML exceptions.
• Error email alerts can be enabled/disabled by updating the custom metadata type record LoggerParameter.SendErrorEmailNotifications (set to true by default)

New Slack plugin package v0.9.2-beta

Fixed #232 - the previous Slack plugin package was failing to install due to the custom metadata type LoggerSObjectHandlerPluginParameter__mdt being consolidated into LoggerParameter__mdt. Note: this plugin is still in beta - there are some upcoming plugin changes planned in #177 and within the plugin framework itself, so this plugin should still be considered a work-in-progress.

• Created new Slack plugin package v0.9.2-beta (based on v4.6.9)
• Updated the Slack README

New Log__c & LoggerSettings__c fields

⚠️ For orgs that are upgrading to this version: you may need to review & update your org's configurations - this release includes 2 new fields on the LoggerSettings__c custom hierarchy settings.

New field Log__c.Scenario__c

Closed #217 by adding a new field suggested by @fentes, Log__c.Scenario__c, that can be set via Apex, Flow and lightning components. This field is provided as a way for org's to self-identify the context of the current transaction. It fully relies on the org's metadata to handle setting this - nothing within Nebula Logger automatically sets this field. In the event that the scenario is set multiple times in a single transaction, then the last scenario specified will be the value used for Log__c.Scenario__c.

Conceptually, this serves a similar purpose to the tagging system - however, tagging is more focused on identifying certain LogEntry__c records, where as the Scenario field is focused on identifying a particular Log__c record.

	Scenario Field	Tagging System
Object	Log__c object - stored in Log__.Scenario__c	LogEntry__c object - related via LogEntryTag__c junction object
Usage	Only 1 scenario can be stored per transaction/Log__c record	Supports adding multiple tags to each LogEntry__c record

Specifying Scenario in Apex

When logging from within Apex, simply call the method Logger.setScenario(String scenario) before calling Logger.saveLog() to specify the current transaction's scenario.

Logger.info('some log entry created BEFORE specifying a scenario'); // This log entry will still have the scenario set, even though it's logged before `setScenario(String)` is called
Logger.setScenario('an example transaction scenario name');
Logger.info('some log entry created AFTER specifying a scenario');
Logger.saveLog();

Specifying Scenario in Lightning Components

When logging from within lightning web components and aura components, you can specify the scenario by calling the logger function setScenario(scenario) - this function expects a String to be passed as the parameter. This example shows a basic example of how you can specify the log's scenario and save any pending log entries.

saveLogExample() {
    const logger = this.template.querySelector('c-logger');
    logger.setScenario('some.scenario');
    logger.saveLog();
}

Specifying Scenario in Flow

With adding a log entry from Flow, you can now optionally set the transaction's scenario, using the provided property Scenario - this property is available in all 3 Flow classes (FlowLogEntry, FlowRecordLogEntry, and FlowCollectionLogEntry).

Scenario Field in Log__c List Views

The new Scenario__c field is now included in the "All Logs" list view - you can also add the new field to any of your own list views.

Scenario Field on Log__c Detail Page

The new Scenario__c field is also included on the Log__c record's detail page, under the section "Log Management"

Manually Updating the Scenario Field via Log's "Manage" Quick Action

In some situations, you may want to manually change the value of the field Log__c.Scenario__c - this can now be done using the "Manage" quick action. Simply click the "Manage" button on a Log__c record (or select multiple logs from a list view and click "Manage"), and you can then update the field's value.

New field Log__c.LoggerVersionNumber__c

Another field has also been included to store which version of Nebula Logger created the Log__c record. This will will be helpful in trying to troubleshoot any issues/questions with logging. It also provides a way to know which version is deployed to orgs that are using the unpackaged metadata instead of the unlocked or managed packages (i.e., the metadata has been deployed directly to an org).

New LoggerSettings__c fields

Added 2 new LoggerSettings__c fields to provide a little more control. Both are enabled by default, but to help with performance, these settings should typically be disabled in production unless you are actively troubleshooting an issue.

• IsApexSystemDebugLoggingEnabled__c - When enabled, Logger will automatically call Apex's System.debug() when logging via Apex, Flow/Process Builder, or Lightning Components
• IsComponentConsoleLoggingEnabled__c - When enabled, Logger will automatically call the browser's console.log() function when logging via Lightning Components

LogBatchPurger Enhancement

Closed #223 by adding an extra filter in LogBatchPurger so that any Log__c records with 0 log entries will be deleted, regardless of log's the retention date

Auth.RegistrationHandler Logging Bugfix

• Fixed #224 by adding an internal check in Logger for UserInfo.getSessionId() == null to avoid an uncatchable error that can occur when calling System.Request.getCurrent()

Code Quality & Pipeline Enhancements

A few other changes have been included to improve the overall code quality:

• Enabled more ESlint rules for lwc & aura, fixed several reported issues
• Enabled more PMD rules for Apex, fixed several reported issues
• Automated creating unlocked package version and updating sfdx-project.json + README.md
• Added check in pipeline to verify that the current package version number hasn't already been released
• Added check in pipeline to verify that Apex docs have been generated & committed

Custom metadata type optimizations

⚠️ For orgs that are upgrading to this version: you may need to review & update your org's configurations - this release includes several changes to the LoggerSettings__c custom hierarchy settings, and several old custom metadata types have been consolidated into a new custom metadata type LoggerParameter__mdt.

Custom metadata type (CMDT) optimizations

• Created LoggerParameter__mdt to consolidate/replace several old custom metadata types. This new CMDT uses key-value pair approach for any system-wide configurations, and can be used by plugins for storing any plugin-specific configurations. These old custom metadata types will no longer be used going forward
  • LoggerSObjectHandler__mdt
  • LoggerSObjectHandlerParameter__mdt
  • LoggerSObjectHandlerPluginParameter__mdt
• Renamed LoggerSObjectHandlerPlugin__mdt custom metadata type to LoggerPlugin__mdt
• Fixed #210 reported by @arbokrad - Deprecated LoggerSettings__c.SystemLogMessageFormat__c, replaced it with CMDT-driven LoggerParameter.SYSTEM_DEBUG_MESSAGE_FORMAT
• Deprecated LoggerSettings__c.EnableSystemMessages__c, replaced it with CMDT-driven constant LoggerParameter.ENABLE_LOGGER_SYSTEM_MESSAGES
• Removed method overloads in LoggerParameter - all data type-based methods now require a defaultValue to be passed. This ensures that everything still works, even if the corresponding CMDT is missing/deleted in an org.

The old, deprecated custom metadata types

The new LoggerParameter__mdt custom metadata type records

Other included changes:

• Fixed another issue reported by @arbokrad where LogEntryEventBuilder.setMessage() should be called last in some Logger static methods so that additional fields can be used when calling System.debug()
• Fixed #213 reported by @vr8hub and some other scenarios related to logging SObject and List<SObject>
  1. Fixed - Logging failed when logging a record collection (List<SObject>) where the first record was null
  2. Fixed - Logging failed when logging an empty record collection
  3. Improved - Logging "worked" when logging a null record or null record collection, but there was no clear indication on the LogEntry__c record that you had even tried to log a record/record collection. Now, it will log the word "null" in the field RecordJson__c, and "Unknown" in the fields RecordSObjectClassification__c and RecordSObjectType__c
  4. Fixed - Data masking rules were not being applied to record collections (List<SObject>). Previously, data masking was only being applied when logging a single SObject record
• PR #215 - thanks to @dancinllama for improving both the code quality AND code documentation by fixing several PMD rule violations, including adding missing JavaDoc/JavaDoc parameters 🥇 . The new & updated JavaDoc comments have also been incorporated into the Apex Documentation site
• Deprecated Log__c.OrganizationInstanceReleaseCycle__c field - since there's no automatic way to determine it, it requires updates every release, and it doesn't seem worth maintaining it at this time
• Deleted test classes that had accidentally been duplicated in a previous release
• Switched to using lint-staged.config.js for more control over pre-commit hook scripts - thanks to @jamessimone for figuring this out!

Many thanks to @arbokrad, @vr8hub, @dancinllama, and @jamessimone for all of the amazing help this release!! 🥳