Added new field Log__c.HasComments__c

Core Unlocked Package Changes

• Added new Boolean field Log__c.HasComments__c that's automatically set in the LogHandler class, based on if the field Log__c.Comments__c is populated. Since the field Log__c.Comments__c is a long textarea field, it can't be filter in SOQL, list views, etc. which makes it very difficult to find log records where someone has entered comments. The new Boolean field is set BEFORE_INSERT and BEFORE_UPDATE - existing records (in orgs that are upgrading) will need to be re-saved in order to have the new field correctly populated.

Updated Logger.getUserSettings() to set defaults based on the environment type

Core Unlocked Package Changes

• Updated LoggerSettings__c fields LoggingLevel__c, IsApexSystemDebugLoggingEnabled__c, and IsJavaScriptConsoleLoggingEnabled__c to make the default values be the recommended values for production orgs
• Closed #364 by updating Logger.getUserSettings() to set some field values based on if the current org is a sandbox. This also applies when using the included 'Logger Settings' tab (which displays the LWC loggerSettings).
  • In production, the default field values are now:
    • LoggingLevel__c now defaults to 'INFO'
    • IsApexSystemDebugLoggingEnabled__c and IsJavaScriptConsoleLoggingEnabled__c default to false
  • In sandboxes & scratch orgs, the default field values are now:
    • LoggingLevel__c now defaults to 'FINEST'
    • IsApexSystemDebugLoggingEnabled__c and IsJavaScriptConsoleLoggingEnabled__c default to true
• Updated LoggerEngineDataSelector class to still leverage data cached in Platform Cache (if available), even if querying is disabled for a particular method
• Added the System namespace to all references to the FeatureManagement class - this helps avoid naming collisions in orgs using the unlocked package that have a custom class with the same name
• Removed some lingering references to Logger in LogEntryBuilder & LogEntryBuilder_Tests, which finishes up some ongoing tech debt cleanup to make LogEntryEventBuilder independent/unaware of Logger

Pipeline Improvements

• Made test execution faster in the pipeline by updating build.yml to skip unnecessary code coverage calculations for all test runs except for the final synchronous run in the Experience Cloud scratch org (when code coverage data is uploaded to Codecov.io)

Configurable Platform Cache Partition Name

Core Unlocked Package Changes

• Added new CMDT record LoggerParameter.PlatformCachePartitionName to control which platform cache partition is used for caching

  

• Updated LoggerCache to gracefully handle a nonexistent Platform Cache partition - it internally falls back to using the transaction cache, which doesn't rely on Platform Cache. This is helpful in ensuring that Nebula Logger still works, even if the LoggerParameter.PlatformCachePartitionName record has been misconfigured and/or the corresponding platform cache partition cannot be found.

Pipeline Improvements

• Updated codecov.yml to ignore sample metadata used in the pipeline for creating an Experience Cloud site - this was previously skewing the code coverage results for the repo, since these classes are only used by the pipeline for testing purposes, the code coverage of these classes is irrelevant

Migrated to new System.Assert class, added System namespace to several references

Core Unlocked Package Changes

This release doesn't have any functional changes (hopefully 😅) - it just contains some tech-debt & cleanup in several classes, and it was cleaner to do this as standalone release.

• Migrated all asserts to use the new class System.Assert
• Added the System namespace to all of the below references - this helps avoid naming collisions in orgs that have custom classes with 1 (or more) of these names
  • Classes
    • Exception, AuraHandledException, CalloutException, and IllegalArgumentException
    • Http, HttpRequest, and HttpResponse
    • SObjectAccessDecision
    • UserInfo
  • Enums
    • AccessType
    • LoggingLevel

New Indicator Icons

Core Unlocked Package Changes

• Updated formula fields on LogEntry__c to replace old flag icons with emojis that are more visually distinct from one another

  

• Updated format of LogEntry__climits formula fields to display percentage first (after new indicators) with limit used & max fields displayed in parenthesis

Both of these changes are shown in this screenshot

• The "SOQL Queries" formula field shows an error (⛔) since 90-100% of the limit has been used (94 out of 100 queries)
• The "DML Statements" formula field shows a warning (⚠️) since 80-90% of the limit has been used (127 out of 150 DML statements)
• The remaining formula fields show a checkbox (✅) since less than 80% of the limits have been used (with corresponding values for Used / Max in parenthesis)

Enhancements for Log Entry Event Stream Tab/LWC

Core Unlocked Package Changes

Another stellar community contribution from @mar-ben - this release provides several enhancements to the logEntryEventStream LWC that's used for monitoring published LogEntryEvent__e platform event records.

1. Added split-view toggling - you can now close & open the filter menu (shown on the left side of the LWC)

2. Added tabular view - using the new "Display As" button (shown in the top-right of the LWC), you can switch between the console view & the new tabular view. The list of fields displayed can be configured in the LoggerParameter__mdt object by updating the record LoggerParameter.LogEntryEventStreamDisplayFields

3. Added full-screen mode - using the new "Expand"/"Contract" button (shown in the top-right of the LWC), you can also switch to a larger view so you can more easily see the LogEntryEvent__e data.

Thanks again to @mar-ben for the fantastic enhancements!

Track When An Admin Logs In As Another User

Core Unlocked Package Changes

Closed #396 by adding new fields & logic to determine if the current user (stored in Log__c.LoggedBy__c) is being impersonated by another user

• Added config & code to track impersonators using the Login As feature - this information is now tracked in the new field LogEntryEvent__e.ImpersonatedById__c and Log__c.ImpersonatedBy__c

  

• Added new class LoggerSObjectProxy with inner classes that provide representations of problematic SObject Types AuthSession, LoginHistory and Network. This simplifies some of the downstream code, and makes things easier to test.

• Fixed an unreported SObjectException that would occur when logging a record ID for a template object, such as CaseComment, CaseHistory, AccountHistory, etc., with the error System.SObjectException: Cannot locate Apex Type for ID

Thanks to @surajp, @bussemac, @jkranz-rk, @jamessimone, and @nojanv for all of the help with this getting this new feature released!

v4.9.0 - Winter '23 Release

Managed Package Release

This release is for both the unlocked package (as always), as well as the managed package!

⚠️ For orgs that are upgrading to this version of the managed package: there are several new features & feature flags that have been introduced since v4.8.0 of the managed package to provide configurable options to optimize Nebula Logger declaratively, and you may want to customize these new options to best suit your needs. Some of the new items includes:
https://github.com/jongpie/NebulaLogger/releases/tag/v4.8.4

• Optional usage of Platform Cache to provide org & session caching of data & metadata used by Nebula Logger. You may want to customize the cache partition size based on your org's available cache space (or disable this feature via a new LoggerParameter__mdt record, if you don't want Nebula Logger to use platform cache).
• New LoggerParameter__mdt records to control Nebula Logger's querying of data it's recommended that _### you review the changes in v4.9.0 prior to upgrading in your org to ensure that LoggerSettings__c and LoggerParameter__mdt records in yo**_**ur org, since some configuration options have changed. If you use the managed package & are upgrading,
• New custom object LoggerScenario__c & expanded overall functionality of scenario-based logging via the methods Logger.getScenario(String), Logger.setScenario(String)andLogger.endScenario(String)`

You can see everything that's change between v4.8.0 and v4.9.0 by reviewing:

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

Core Unlocked Package Changes

Metadata API Version

• Updated all metadata from API v55.0 (Summer '22 release) to v56.0 (Winter '23 release)
• Removed the now-deprecated picklist value "v55.0 - Summer '22 Release" in the field Log__c.ApiVersion__c

Updated Visibility of Apex Methods

Updated the following methods from public to global so that they're now available in the managed package, using the Nebula namespace - this should not have any direct impact on the unlocked package's functionality

• Logger class static methods

  • Logger.getVersionNumber()
  • Logger.endScenario(String scenario)
  • Logger.ignoreOrigin(System.Type apexType)

• LogEntryEventBuilder class instance methods

  • LogEntryEventBuilder.getLogEntryEvent() - returns an instance of LogEntryEvent__e

Metadata Cleanup

• Updated the descriptions in several custom metadata type objects and LoggerParameter__mdt records to provide more details & better reflect the current usage of each item

Bugfixes

• Fixed an System.InvalidParameterValueException that could occur in LogBatchPurgeScheduler when the batchSize value was null - now, LogBatchPurgeScheduler checks for null values & uses a default value instead.
  • The default batchSize value has also been changed from 200 to 2000. The LogBatchPurger job has always used 200 as the default value because the original code (written years ago) wasn't scalable - it was rewritten to be much more scalable in v4.6.0 when the objects LogEntryTag__c and LoggerTag__c were introduced, but the default batch size was never increased.

Better Handling of Apex Class Name Collisions

For orgs that use the unlocked package (core package), installation issues can occur if the org has a custom Apex class that matches the name of a standard Apex class, such as Limits, Network, Test, Type, etc. References throughout the codebase have been updated to include the System namespace prefix to ensure that this type of metadata collision does not prevent installation of Nebula Logger.

Query Optimizations & More Configurable Controls

Core Package Changes

Synchronous Context Optimizations

Several enhancements have been made to reduce the overhead that Nebula Logger consumes when logging - these enhancements help with some platform limits, such as query limits, CPU time limits, etc. (closes #311 reported by @LawrenceLoz). Many thanks again to @LawrenceLoz for doing some stellar analysis on the codebase to identify some of these optimizations.

• Added new LoggerParameter__mdt record EnableStackTraceParsing to disable stack trace parsing org-wide. Although parsing stack traces can help provide contextual info for reporting, the code consumes CPU time in Apex - orgs can now choose if they want to disable this functionality to improve Nebula Logger's performance.
• Added new LoggerParameter__mdt records to enable/disable if LogEntryEventBuilder queries run synchronously (default behavior). When these records are disabled (Value__c = 'false'), the corresponding queries run asynchronously after platform events are published. This means that the corresponding fields aren't set on LogEntryEvent__e, but are still populated on Log__c and LogEntry__c. Four (4) new custom metadata records are included:
  1. LoggerParameter.QueryAuthSessionDataSynchronously
  2. LoggerParameter.QueryNetworkDataSynchronously
  3. LoggerParameter.QueryOrganizationDataSynchronously
  4. LoggerParameter.QueryUserDataSynchronously
• Updated Logger class to internally cached the value of UserInfo.getSessionId(). The original (erroneous) assumption was that the platform would handle caching this, but repeated calls to the method seem to consume additional CPU time - the value is now cached in a private constant.

Caching System Improvements

Platform Cache is now being leveraged to supplement the existing transaction caching (partially closes #311, and closes #389 reported by @rmccu)

• Added platform cache partion LoggerCache that comes with 3MB allocated, based on the 3MB that Salesforce provides for security-approved managed packages. Sadly, Nebula Logger has not yet gone through this process yet, but still seemed like a sensible default size to use.
  • 1MB allocated to the org partition
  • 2MB allocated to the session partition
• Updated Apex class LoggerCache to now support 3 types of caching:
  1. LoggerCache.getTransactionCache(). This is the existing caching system that's been used for a few releases. It caches values in a transaction using a private static final Map<String, Object> constant. This is still used internally throughout LoggerCache to supplement some limitations with platform cache, such as not being able to cache null values
  2. LoggerCache.getOrganizationCache(). This leverages the org partition of Platform Cache
  3. LoggerCache.getSessionCache(). This leverages the session partition of Platform Cache
• Updated all existing caching in Nebula Logger to now leverages platform caching by default.
• Added a new LoggerParameter__mdt record 'UsePlatformCache' to control if Nebula Logger leverages platform cache. When 'UsePlatformCache' is disabled (Value__c = 'false'), Nebula Logger will only use Logger.getTransactionCache() (which is existing behavior before platform cache was introduced).

Large Data Volume (LDV) Optimizations

I've included some query-related enhancements to address some of the performance problems that @rmccu brought up for orgs with large data volumes (2+ millions Log__c records created daily)

• Added new LoggerParameter__mdt records to completely disable certain queries executed by Nebula Logger (closes #390 reported by @rmccu). Some of the queries used by Nebula Logger can perform poorly in orgs with large data volumes - the new records provide a way for orgs to completely disable certain queries, with the tradeoff that the corresponding fields will be null. Seven (7) queries can now be fully disabled - there are still some other queries throughout Nebula Logger that don't have this option, but these should be the most critical queries.
  1. LoggerParameter.QueryApexClassData - when disabled, the ApexClass object is not queried, and the relevant fields on LogEntry__c are null
  2. LoggerParameter.QueryAuthSessionData - when disabled, the AuthSession object is not queried, and the relevant fields on LogEntry__c are null
  3. LoggerParameter.QueryFlowDefinitionViewData - when disabled, the FlowDefinitionView object is not queried, and the relevant fields on LogEntry__c are null
  4. LoggerParameter.QueryNetworkData - when disabled, the Network object is not queried, and the relevant fields on LogEntry__c are null. Note: this only applies to orgs that use an Experience Cloud site (stored in the Network object)
  5. LoggerParameter.QueryOrganizationData - when disabled, the Organzation object is not queried, and the relevant fields on LogEntry__c are null
  6. LoggerParameter.QueryRelatedRecordData - when disabled, the dynamic queries used to query record names (based on the field LogEntry__c.RecordId__c) are not executed, the field LogEntry__c.RecordName__c is null
  7. LoggerParameter.QueryUserData - when disabled, the User object is not queried, and the relevant fields on LogEntry__c are null

Bugfixes

• Fixed LogEntry__c.Timestamp__c being inaccurately set in some edge cases. This was an unreported bug found where LogEntryEvent__e.TimestampString__c could be out of sync with LogEntryEvent__e.Timestamp__c, resulting in inaccurate data being stored in LogEntry__c.Timestamp__c. The bug has been fixed & some additional tests have been added to ensure that this continues to behave as expected.

Data Model Changes

• Added new fields LogEntryEvent__e.RequestId__c and Log__c.RequestId__c to store the value of System.Request.getCurrent().getRequestId(). In versions v3.1.0 through v4.7.2, this value was used for Log__c.TransactionId__c, but reverted to using a more reliable custom UUID in v4.7.3 (the original solution). The new RequestId__c fields provides a way to still report on this value, which can be helpful for tying Nebula Logger's data back to platform data & logs.

Test Improvements

• Fixed #393 (reported by @mykhaylo-partyka) by removing an unnecessary & problematic call to List.sort() on the expected query results
• Added new ApexTestSuite LoggerExtraTests (only deployed to/used by the pipeline for integration tests)
• Added more integrations tests, primarily for Experience Site (Community/Network/Portal/too-many-names-ahhh) testing around Network querying & setting of related fields
• Make LoggerEngineDataSelector and LogManagementDataSelector classes & methods virtual & implemented test implementations in the respective test classes LoggerEngineDataSelector_Tests and LogManagementDataSelector_Tests to provide a cleaner way to test query executions within Nebula Logger's codebase.
• The test implementations currently usedin test classes still execute all of the related queries, so the queries aren't returning mock values (when possible) just yet. This PR has most of the foundational changes need to support full mocking, but I'm planning to revisit some of the tests throughout the codebase in a future release to implement mock return values when possible. That will make it easier to test queried data in general, and should also give the tests classes another nice boost in test speed (in addition to some other substantial test speed improvements made in v4.7.1).

Experience Site Test Metadata Improvements

These changes only impact the pipeline to help validate logic related to orgs that use Nebula Logger for Experience Cloud sites (aka Community Cloud) - these changes don't have any direct functional changes to Nebula Logger

• Added high-volume traffic Community profile & related metadata changes for pipeline testing purposes
• Added more Apex tests for Experience Cloud scenarios in the extra-tests folder. These tests are only used in the pipeline - they are not included in the core package.

Async Failure Additions Plugin Package Changes

Created v1.0.2 of the Async Failure Additions plugin

• @jamessimone implemented an incredible, new feature for this plugin to automatically log Flow errors that occur in Screen Flows, using the platform event FlowExecutionErrorEvent (closes #372 - implemented in #392)

Slack Plugin Package Changes

Created v1.5.1 of the Slack plugin

• Updated the formatting of the field 'Last Log Entry Message' to handle line breaks

Many thanks to @jamessimone , @LawrenceLoz, @rmccu, and @mykhaylo-partyka for all of the help with this release!

Improved LogEntry__c Formula Fields for Limits

For each transaction limit returned in the Limits class, LogEntry__c has 3 fields: "limit name" used, "limit name" max, and a "limit name" formula field that shows "Used / Max". This is helpful for quickly checking how much of each limit has been consumed. However, for some limits with a large max value (such as Heap Size), the formula field does not format the numbers (which is apparently quite difficult to do in a formula field), so you end up with values like "12425 / 6000000" which can sometimes be hard to read at glance, it makes it hard to tell what percentage of the limit has been consumed, as shown in this screenshot:

To help with this, 2 changes have been made to all of the limits formula fields on LogEntry__c:

1. Added a flag indicator based on the percent of the limit used, using somewhat arbitrary-but-sensible ranges:
   • 90% or more of a limit consumed: a red flag is displayed
   • 80-90% of a limit consumed: a yellow flag is displayed
   • Less than 80%: a green flag is displayed
2. Added percentage calculation based on the limit used: to make it easier at a glance to know how much of a limit has been consumed, each field now displays the percent used in parenthesis

With these changes in place, the limits are now much easier to understand at a glance - the colored flags help indicate if there are any limits to be worried about (red & yellow flags), and the percentage calculation tells you exactly how close you are to a particular limit: