Made the behavior of Logger.setScenario() configurable via new LoggerParameter__mdt record

⚠️ For orgs that are upgrading to this version & use the scenario functionality (stored in Log__c.Scenario__c): you may need to update the new CMDT record in your org, if you prefer to keep the previous behavior for setting scenarios. In previous releases, the last scenario specified in a transaction would be used, but going forward, by default, the first scenario specified will now be used.

Resolved #317 by adding a new CMDT record LoggerParameter.UseFirstSpecifiedScenario to control if the first or last specified value is used when Logger.setScenario(String) is called multiple times in the same transaction.

When the CMDT record has Value__c = 'true' (the new default value), this script will output 'first' for both debug statements:

Logger.setScenario('first');
System.debug('scenario 1==' + Logger.getScenario());
Logger.setScenario('second');
System.debug('scenario 2==' + Logger.getScenario());

When the CMDT record has Value__c = 'false', this script will output 'first' for the... first debug statement, and 'second' for the second. This configuration
provides the same behavior used in prrvious releases (buy it will not be the defauly behavior going forward)

New Method Logger.logDatabaseErrors()

Resolve #295 by adding a new method Logger.logDatabaseErrors(), including several overloads for using LogMessage/String, as well as the different database result classes. When this method is called, if the list of database results includes 1 or more errors (based on isSuccess() == false), then a new log entry is added, and the JSON of any unsuccessful database results is serialized/stored in the log entry.

The full list of method overloads is:

global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, LogMessage logMessage, List<Database.DeleteResult> deleteResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, String message, List<Database.DeleteResult> deleteResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, LogMessage logMessage, List<Database.MergeResult> mergeResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, String message, List<Database.MergeResult> mergeResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, LogMessage logMessage, List<Database.SaveResult> saveResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, String message, List<Database.SaveResult> saveResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, LogMessage logMessage, List<Database.UpsertResult> upsertResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, String message, List<Database.UpsertResult> upsertResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, LogMessage logMessage, List<Database.UndeleteResult> undeleteResults);
global static LogEntryEventBuilder logDatabaseErrors(LoggingLevel loggingLevel, String message, List<Database.UndeleteResult> undeleteResults);

Thanks to @jamessimone for the great suggestion & code review!

Added query selector classes, fixed some recurring bugs

Enhancements

This PR is primarily focused on adding some optimizations & cleanup as pre-work to implementing some stellar suggestions from @LawrenceLoz that will be implemented as part of #311 (originally discussed in #303)

• Added new Apex selector classes LoggerEngineDataSelector and LogManagementDataSelector to centralize (almost) all queries throughout the codebase
• Added new Apex class LoggerCache to centralize caching of query results

Bugfixes

• Possibly fixed an issue discussed in #310 with @reitffunk by reverting to only using a UUID for the transaction ID (instead of using System.Request.getCurrent().getRequestId())
• Fixed #313 reported by @jverelst by switching to using a combination of Logger's transaction ID + an incremented counter to dynamically creating unique usernames during tests. This should ensure that the generated username is unique both within a transaction, and across all Salesforce orgs
• Fixed #276 (again) by moving when an email is added to the constant LoggerEmailSender.SENT_EMAILS, which was previously causing test failures in orgs with email deliverability disabled.
  • Scratch orgs also can't have deliverability disabled (very frustrating), so I also separately changed email deliverability to 'System Email Only' in the pkg demo org that's used in the pipeline, which should help ensure everything is working going forward 🤞
• Added missing access to the class LoggerSObjectMetadata to permission sets 'LoggerAdmin' and 'LoggerLogViewer'
  • This solves an issue in orgs where Apex access is enforced - without the class access, the Logger Settings tab/LWC would throw an error on page load
• Changed the approach used to originally to solve #219 by using the User Type (UserInfo.getUserType()) of the user's profile, which seems to be a more stable option than the old approach of checking the profile's user license name
  • This was originally reported months ago by @solo-1234, who encountered this issue again. I was not able to reproduce the issue, but using User Type seems like a better approach anyway, and will hopefully resolve any lingering issues with the Guest User
  • I tried to find an option that didn't rely on a hardcoded String, but so far, have not found any other way to determine it

Metadata Cleanup

• Deleted some deprecated LoggerParameter__mdt records - these were deprecated in v4.7.1, but I forgot to remove them from the repo/package
• Eliminated layer-specific test suites within core - as of v4.7.1, the tests are super fast anyway, so the 'LoggerCore' test suite covers everything + makes maintenance easier
• Moved the 'LoggerLogCreator' permission set back to being part of the logger-engine layer

Async Failures plugin

• Added a missing CMDT record LoggerSObjectHandler.BatchApexErrorEvent for the async failures plugin (and created a new package version that includes the CMDT record)

Bugfix for setting parent log transaction IDs, new Async Failures Additions plugin

Core Package Changes

• Fixed #300 by adding a new field Log__c.ParentLogTransactionId__c and updated trigger handler logic to optionally set Log__c.ParentLog__c when the parent log is found (or skips it when the parent log is not found)
  • The Log__c flexipage and page layout now use a new formula field Log__c.ParentLogLink__c to display either a link to ParentLog__c when set or the text value of ParentLogTransactionId__c
• Updated the description of perm set LoggerLogCreator to indicate that it's currently optional, but might be needed in the future
• Optimized LogEntryEventHandler.TAG_ASSIGNMENT_RULES by adding lazy-loading (discussed in #303) and adding a check on LogEntryTagRule__mdt.getAll().isEmpty() == true to minimize the usage of querying on LogEntryTagRule__mdt
• Cleaned up some methods in Logger_Tests, and added TODOs for several test methods that will eventually be rewritten in a future release
• Removed some stale @SuppressWarnings annotations in a couple of Apex classes-
• Promoted a few buried strings within Apex classes to be constants, and a cleaned up a few other small code bits
• Removed overload for LoggerMockDataCreator.createAggregateResult(Map<String, Object>) since the current mocking approach doesn't/can't actually set any fields on the mock AggregateResult
• Added new text field LoggerSObjectHandler__mdt.SObjectTypeOverride__c as a way to support triggers on objects that are not supported via EntityDefinition lookups
• Fixed #308 by adding the Schema namespace to a reference of FieldSetMember (now Schema.FieldSetMember)
• Further fixed issues like #308 by adding empty classes with problematic names (FieldSet, FieldSetMember, SObjectField, SObjectType and Test for now) - this will cause deployment errors in the pipeline if there are any references that don't use the System/Schema namespaces

New Async Failures Additions Plugin

@jamessimone created a new plugin (implemented in #309), this plugin adds support for logging asynchronous batchable and queueable exceptions.

Batchable Error Logging

All a batch class needs to do is implement the marker Database.RaisesPlatformEvents interface and create a LoggerParameter__mdt record where the Value field matches the name of the batch class you are looking to add logging for, and the DeveloperName (the "Name" field) starts with BatchError:

// the class MUST implement Database.RaisesPlatformEvents for this to work correctly!
public class MyExampleBatchable implements Database.Batchable<SObject>, Database.RaisesPlatformEvents {
    // etc ...
}

And the CMDT record:

Once you've correctly configured those two things (the marker interface Database.RaisesPlatformEvents on the Apex batchable class, and the Logger Parameter CMDT record), your class will now log any uncaught exceptions that cause that batch class to fail unexpectedly.

Queueable Error Logging

If you have Apex classes that implement System.Queueable, you can add error logging with some minimal code additions:

public class MyExampleQueueable implements System.Queueable {
    public void execute (System.QueueableContext qc) {
        System.attachFinalizer(new LogFinalizer());
    }
}

If you'd like to do additional processing, you can alternatively choose to extend LogFinalizer:

public class MyCustomFinalizer extends LogFinalizer {
    protected override void innerExecute(System.FinalizerContext fc) {
        // do whatever you'd like!
        // errors will be logged automatically in addition to what you choose to do here
        // no need to call Logger.saveLog() manually on this code path
    }
}

Promoted All Plugin Packages

Previously, the package plugins had not been promoted, which prevented them from being installed directly into production. The most recent package versions for each plugin has now been promoted, allowing all plugins to now be installed into production. At the moment, there are 5 plugins available:

• Async Logging Additions plugin (brand new, see above)
• Big Object Archiving plugin
• Log Retention Rules plugin
• Logger Admin Dashboard plugin
• Slack plugin

Note that several plugins are still considered to be in beta - the code has been tested and everything is expected to work in production, but as some plugins are relatively new, there may be some bigger changes between releases (depending on community feedback about new features & bugfixes).

Pipeline Changes

• Added CODEOWNERS file
• Changed build.yml so that the managed package build is a dependency for creating the unlocked package. This will add more time to the build, but it will ensure that the managed package (the more problematic package) can be created before creating the unlocked package
• Fixed some broken images in some plugin README.md
• Fixed some dependabot alerts by adding specific versions of some packages as dependencies in package.json & recreating package-lock.json

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)