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

Deprecated & replaced BrowserUrl__c fields with new BrowserAddress__c fields

Thanks to @Ben-Nathan-CTM for reporting this bug!

Core Unlocked Package Changes

This release fixes #696 by making a couple of changes to how the browser's address is captured when logging in lightning components

• Updated the Apex class ComponentLogger to auto-truncate JS browser fields (including LogEntryEvent__c.BrowserUrl__c)
  • The public property ComponentLogger.ComponentLogEntry.browserUrl is now deprecated & will be deleted in a future release. It's only intended to be used internally by Nebula Logger, so this hopefully doesn't impact anyone - but mentioning it here, just in case 😉
• Replaced the text (255) fields BrowserUrl__c on LogEntryEvent__e and LogEntry__c with new long textarea (2000) fields BrowserAddress__c
  • The existing BrowserUrl__c fields are too short to store some long URLs (such as URLs with a lot of parameters), and the existing fields can't be converted from text(255) to long text area fields, so new fields are needed
  • The existing BrowserUrl__c fields will still be populated for foreseeable future (with a truncated value), but they are now considered deprecated - any references in reports, list views, queries, etc. should be updated to use the new BrowserAddress__c fields
• Documentation: added missing data classification metadata to several existing browser fields on LogEntryEvent__e and LogEntry__c
  • This doesn't impact any functionality, it's just for documentation purposes

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.14...v4.13.15

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

Custom Field Mappings Support

Thanks to @pankaj0509 and @codejester90 for suggesting this enhancement & providing some great feedback!

Core Unlocked Package Changes

This release resolves #655 by adding support for defining, setting, and mapping custom fields within Nebula Logger's data model. This is helpful in orgs that want to extend Nebula Logger's included data model by creating their own org/project-specific fields.

Adding custom fields to the platform event LogEntryEvent__e

To get started, the first step is to add a field to the platform LogEntryEvent__e`

• Create your own custom fields on LogEntryEvent__e. Any data type supported by platform events can be used.

  • In this example, a custom text field called SomeCustomField__c has been added:

    

• Populate your own custom fields in Apex by calling one of the two new instance methods on LogEntryEventBuilder:

  1. setField(Schema.SObjectField field, Object fieldValue)
  2. setField(Map<Schema.SObjectField, Object> fieldToValue)

For now, this functionality is available in Apex. Long-term, equivalent functionality will hopefully be added for Flow & Lightning Components. Here is an example of using the 2 new methods in Apex:

Logger.info('hello, world')
    // Set a single field
    .setField(LogEntryEvent__e.SomeCustomTextField__c, 'some text value')
    // Set multiple fields
    .setField(new Map<Schema.SObjectField, Object>{
        LogEntryEvent__e.AnotherCustomTextField__c => 'another text value',
        LogEntryEvent__e.SomeCustomDatetimeField__c => System.now()
    });

Adding custom fields to the custom objects Log__c, LogEntry__c, and LoggerScenario__c

If you want to store the data in one of Nebula Logger's custom objects, you can follow the above steps, and also...

• Create an equivalent custom field on one of Nebula Logger's custom objects - right now, only Log__c, LogEntry__c, and LoggerScenario__c are supported.

• In this example, a custom text field also called SomeCustomField__c has been added to Log__c object - this will be used to store the value of the field LogEntryEvent__e.SomeCustomField__c:

  

• Create a record in the new CMDT LoggerFieldMapping__mdt to map the LogEntryEvent__e custom field to the custom object's custom field, shown below. Nebula Logger will automatically populate the custom object's target field with the value of the source LogEntryEvent__e field.

  • In this example, a custom text field called SomeCustomField__c has been added to both LogEntryEvent__e and Log__c.

    

New extra-tests Metadata

To help with testing Nebula Logger, a few new metadata items have been added to the extra-tests directory. This directory is not included in any of Nebula Logger's packages - its metadata is used to help both with automated tests in the pipeline, as well as manual functional tests.

• Added some new custom fields for the objects LogEntryEvent__e, Log__c, LogEntry__c, and LoggerScenario__c to the extra-tests directory to provide sample fields that are only used for testing the custom field mapping functionality
• Added some new CMDT records for the new object LoggerFieldMapping__mdt. These records map the (new) included custom fields (mentioned above)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.13...v4.13.14

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

Improved Fully-Qualified References

Since the unlocked package does not have a namespace, orgs can encounter installation errors for Nebula Logger if the target org has any custom Apex code (classes, enums, interfaces, etc.) with the same name as standard class in the Schema or System namespace (referred to as name shadowing).

This is the same concept & approach as the changes made in several previous releases (listed below) - but my hope is that this PR finally finishes this effort, and all references are now fully qualified.

• v4.9.0
• v4.9.4
• v4.9.6
• v4.12.5

This shouldn't cause any functional changes to Nebula Logger - this is to tidy up existing references to avoid name collisions so that more orgs can use the unlocked package.

Core Unlocked Package Changes

Apex Code Changes

• Switched to using fully-qualified references for these standard classes in the Schema and System namespaces :

  • Schema namespace standard classes
    • ApexClass → Schema.ApexClass
    • ApexEmailNotification → Schema.ApexEmailNotification
    • ApexTrigger → Schema.ApexTrigger
    • AsyncApexJob → Schema.AsyncApexJob
    • BatchApexErrorEvent → Schema.BatchApexErrorEvent
    • CustomPermission → Schema.CustomPermission
    • DisplayType → Schema.DisplayType
    • FlowDefinitionView → Schema.FlowDefinitionView
    • FlowExecutionErrorEvent → Schema.FlowExecutionErrorEvent
    • FlowVersionView → Schema.FlowVersionView
    • PermissionSet → Schema.PermissionSet
    • PermissionSetAssignment → Schema.PermissionSetAssignment
    • SoapType → Schema.SoapType
    • UserRecordAccess → Schema.UserRecordAccess
    • UserRole → Schema.UserRole
  • System namespace standard classes
    • BatchableContext → System.BatchableContext
    • Comparable → System.Comparable
    • Database → System.Database
    • EventBus → System.EventBus
    • FinalizerContext → System.FinalizerContext
    • InstallHandler → System.InstallHandler
    • JSON → System.JSON
    • Matcher → System.Matcher
    • Pattern → System.Pattern
    • PicklistEntry → System.PicklistEntry
    • Queueable → System.Queueable
    • QueueableContext → System.QueueableContext
    • Quiddity → System.Quiddity
    • Request → System.Request
    • RestContext → System.RestContext
    • RestRequest → System.RestRequest
    • RestResponse → System.RestResponse
    • Schedulable → System.Schedulable
    • SchedulableContext → System.SchedulableContext
    • Search → System.Search
    • TriggerOperation → System.TriggerOperation
    • UUID → System.UUID

• Scope creep: fixed some flaky tests in LogBatchPurgeController_Tests

extra-tests Metadata Changes

• Moved the existing name-shadowing classes in the extra-tests directory to be in separate subdirectories (one for each namespace, Schema and System)
• Added several new name-shadowing classes for all of the Schema & System references (mentioned above) that are now using fully-qualified references
  • These classes are deployed in Nebula Logger's pipeline to enforce that the codebase uses fully-qualified references

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.12...v4.13.13

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