Fixed setScenario() function in logger LWC

Thanks to @rcastanosgonzalez for reporting and fixing this bug!

Core Unlocked Package Changes

• Fixed #666 issue in PR #667 by updating the logger LWC's function setScenario() to properly (and always) set the scenario on each log entry. Previously, the value was often incorrectly set to null

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.6...v4.13.7

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

View Log Entry Metadata custom permission

Core Unlocked Package Changes

• Added new custom permission CanViewLogEntryMetadata so that users without query access to ApexClass and ApexTrigger can still see the source code in the LWC logEntryMetadataViewer
• Updated the permission set LoggerAdmin to assign the new custom permission CanViewLogEntryMetadata
• Added some more test methods in LogEntryMetadataViewerController_Tests, and cleaned up some code in LogEntryMetadataViewerController

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.5...v4.13.6

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

Performance Improvements

Change Overview

Emoji legend: 🟢 new, 🗜internal change, ⚠something to be aware of

• 🟢 Adds new Logger Parameter CMDT record, Store Heap Size Limit, which relies on the Store Transaction Limits Logger Parameter record to also be true. When set to true, the LogEntry__c.LimitsHeapSizeUsed__c field is set. When set to false, that particular field is not set, and users of Nebula Logger performing bulk data uploads or other bulk data transactions where logging exists at an individual record level may well want to toggle this parameter to false, as it's the single greatest contributor to CPU speed slowdown when logging.
• 🗜 Centralizes where field truncation is occurring for long text area fields so that less CPU time is spent looping through all of Schema.LogEntryEvent__e prior to publishing platform events
• 🗜 Caches the System.Limits calls that are static for each transaction
• 🗜 Simplifies stack trace parsing so that less CPU time is spent suppressing Nebula Logger classes when parsing
• 🗜 Eliminates duplicated calls to LogEntryEventBuilder.getLogEntryEvent()
• 🗜 Centralizes how database results are logged within Nebula to enable consistent field truncation for any potential errors
• 🗜 Logger class now delegates to LogEntryEventBuilder instead of setting fields on Schema.LogEntryEvent__e directly
• ⚠ Changes how the LogEntry__c.DatabaseResultJson__c stores results: if you were passing a list of results with only one entry in it, that is now recorded as a single entry instead of a single entry in a list
• ⚠ Changes how Schema.LogEntryEvent__e.TimestampString__c is set - previously, consumers could rewrite a Schema.LogEntryEvent__e.Timestamp__c by calling LogEntryEventBuilder.getLogEntryEvent() and resetting that field. Now, Schema.LogEntryEvent__e.TimestampString__c is only set once when a LogEntryEventBuilder instance is first configured and downstream consumers can call the instance method LogEntryEventBuilder.setTimestamp(Datetime timestamp); if they'd like to override the timestamp later on

All of these changes amount to a substantial performance increase, and performance can be monitored using the new LoggerBenchmarking_Tests class

Benchmarking Stats

Here are some stats associated with this change when logging for 500 records (all times reported in milliseconds):

Branch	LoggerBenchmarking_Tests overall	LogEntryEventBuilder.getLogEntryEvent()	LogEntryEventBuilder() constructor	LoggerStackTrace.getCleansedStackTraceLines()
main	16405	1554	4697	1278
main	18178	1690	6309	1360
benchmarking-logger	10377	4511	64	206
benchmarking-logger	10416	4648	67	219

Additionally, LoggerDataStore.EventBus.TruncateStringFields was taking anywhere from ~2130ms to ~2590ms to run in #651 and that method has been eliminated entirely.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.4...v4.13.5

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

Added New Comments__c Field on LoggerParameter__mdt

Core Unlocked Package Changes

• Added new field LoggerParameter__mdt.Comments__c as a place for admins & developers to store notes about why a LoggerParameter__mdt record has been customized.

  • This is only intended for documentation purposes to help admins viewing the record in the org, as well as a way to document customizations in git/VCS

  

• Updated LoggerParameter__mdt records to include the XML node for the new Comments__c field

• Scope creep: added missing project license info in several LWC files

• Scope creep: added .npmrc file to explicitly set the npm registry

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.3...v4.13.4

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

Optionally Enforce Scenario-Based Logging Usage

Core Unlocked Package Changes

• Resolved #645 by adding the ability to optionally enforce using scenario-based logging. This is controlled by a new LoggerParameter__mdt record, RequireScenarioUsage, and is disabled (false) by default.
  • When set to false, specifying a scenario is completely optional.
  • When set to true, a scenario is required to be set before any logging can occur. If a logging method is called &; the current scenario is null/blank, then Nebula Logger will throw a runtime exception.
• Upgraded LoggerScenarioRecordPage flexipage to use dynamic related lists for Log__c and LogEntry__c
• Added missing field permission for Log__c.TransactionScenario__c to LoggerAdmin permission set

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.2...v4.13.3

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

Track OrgLimits data on Log__c

🎉 🪵 💯 Nebula Logger's 100th Release! 💯 🪵 🎉

Yet another neat milestone for the project 🥳

Core Unlocked Package Changes

• Resolved #630 by adding new functionality to automatically track organization limits data, returned by the class System.OrgLimits

  • This data is automatically stored as JSON in the new field Log__c.OrganizationLimits__c

  • You can disable storing this data, using the new LoggerParameter__mdt record StoreOrganizationLimits

  • This data is displayed within a new "Organization Limits" tab on the Log__c flexipage, using a new LWC logOrganizationLimits (shown below). The design of this LWC is intended to mimic the existing formula fields shown on LogEntry__c that are used to track transaction limits.

    

    • For comparison, this image shows the existing formula fields on LogEntry__c that are used to track transaction limits.

      

• Added another new LoggerParameter__mdt record, StoreTransactionLimits, to control if transaction limits are retrieved from the class System.Limits & stored on LogEntry__c

  • Previously, transaction limits were always populated, with no way to disable it - using the System.Limits class does seem to have some overhead (namely, it uses CPU time), so being able to disable this functionality can, hilariously, help to reduce transaction limits usage.

• loggerPageSection LWC changes: Fixed some padding in loggerPageSection.html so it's more consistent with 'real' field section headers

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.1...v4.13.2

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

Apex Observability Enhancements

This release is a big one - and so is the description, to try to cover all of the changes.

Overview

This introduces some very powerful enhancements to improve the observability of Apex code, making it easier for Salesforce experts to answer questions like "what happened in my Apex code?" and "what did my Apex code look like?". It also takes some big steps towards streamlining the fields on LogEntry__c to simplify reporting, and shifting towards using custom LWCs to provide an improved user experience for viewing logging data.

Source Snippets

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

• Origin Source Snippets: Any time you add a log entry in Apex, you will now be able to see a snippet of your Apex code that generated the LogEntry__c record.
• Exception Source Snippets: Any time you include an Apex exception in your log entry, you will now also be able to see a snippet of Apex code that threw the exception.

For example, if you deploy the example Apex class below:

Example Class with Logging

public with sharing class ExampleClassWithLogging {
    public void doSomething() {
        Logger.finest('Starting the doSomething() method!');

        try {
            insertContact('Some Contact Name');
        } catch (Exception ex) {
            Logger.error('An unexpected exception occurred', ex);
            Logger.saveLog();
            throw ex;
        }
    }

    public Schema.Contact insertContact(String contactName) {
        Schema.Contact contact = new Schema.Contact();
        // TODO don't forget to populate the record's required fields
        // before deploying this code to prod!
        insert contact;
        return contact;
    }
}

...if you then run and run new ExampleClassWithLogging().doSomething();, Nebula Logger will generate a new LogEntry__c record with 2 code snippets - one snippet for the origin of the entry, and another snippet for the included exception.

In each snippet, you can see about 12 lines of source code that executed - the relevant line of code is automatically highlighted.

You can also click the 'View Full Source' button to see the entire Apex class or trigger that is currently deployed to the org. The modal even indicates if the source code has been modified since the LogEntry__c was generated, making it easy to know if the snippet on the LogEntry__c is still accurate.

Streamlined Reporting with New Origin & Exception Source Fields

Nebula Logger supports logging in 5 (5-ish) metadata types:

• Apex classes
• Apex triggers
• Flows (and implicitly, Process Builder)
• Lightning web components
• Aura components

This release tries to provide a more consistent set of fields to use for reporting, regardless of which metadata type is using Nebula Logger.

Current State: LogEntry__c Fields Are Not Very Scalable

Originally when Nebula Logger was first created, Apex classes were the only focus - as new metadata types have been added over the years, new fields have also been added LogEntry__c that are specific to each metadata type. For example:

• There are Apex class-specific fields like ApexClassName__c and ApexMethodName__c
• There are Flow-specific fields like FlowActiveVersionId__c
• There are Lightning component-specific fields like ComponentApiName__c and ComponentFunctionName__c

These approach has led to 2 challenges:

• Field Limits. Each custom object in Salesforce has a limit on the number of custom fields, and this approach quickly eats up some of the limit for LogEntry__c.
• Reporting. The current fields don't provide a consistent way to report on the data, you effectively have to use different sets of fields to report on each metadata type. This overcomplicates things for teams that want to monitor & report on support issues.

These challenges have created a cycle of new challenges & issues:

• Not Scalable for Both Origin & Exception Metadata Sources The existing metadata-specific fields (like ApexClassName__c, FlowActiveVersionId__c, ComponentApiName__c, etc) are only for the log entry's origin (i.e., the metadata the generated the log entry). Due to concerns with field limits, there are not equivalent fields for exception details - arguably, it's more important to capture granular details about exceptions (instead of the origin), but the origin fields came first, and exception fields have never been added, which is a big gap in actionable data.
• Not Scalable for All Supported Metadata Types The existing metadata-specific fields don't even cover all supported metadata types. Currently, Apex triggers aren't treated the same as the other metadata types. There are no trigger-specific fields, and most of Nebula Logger's codebase assumes "Apex code" == "Apex class". And while I think that triggers shouldn't contain logic (and thus, shouldn't really be doing any logging directly), the reality is that a lot of Salesforce orgs don't follow this best practice, and Nebula Logger should handle Apex triggers as effectively as it does Apex classes.

Future State: Scalable Exception & Origin Fields

To streamline things, this release introduces 2 sets of fields.

• Origin Source fields - details about the source metadata that generated the log entry
• Exception Source fields - details about the source metadata that generated the exception

Each set of fields consists of ~16 fields (about 16 Origin fields, and about 16 Exception fields). These fields are intended to work for all supported metadata types, which helps to simplify reporting, list views, etc.

The older, metadata-specific fields (like ApexClassName__c, FlowActiveVersionId__c, ComponentApiName__c, etc) will continue to be populated & supported for now, though it is likely that they will eventually be deprecated in the future.

LogEntry__c UI Changes

Overhauled the LogEntry__c flexipage LogEntryRecordPage

As the number of fields on LogEntry__c has grown, the complexity of the LogEntryRecordPage has also grown. This releases adds more tabs to the page's horizontal tab set.

Shifting To Custom LWCs for Nebula Logger's Record Pages

Nebula Logger heavily utilizies App Builder record pages (FlexiPage metadata) for displaying data in Log__c, LogEntry__c, etc - including heavy use of dynamic forms, conditional visibility, and some of the other amazing declarative features. However, there are several new & existing features that would benefit from custom UIs, and this release is the first step in adding new components that will improve the usefulness of the LogEntry__c page.

In particular, this release introduces a few new components, used to display Apex snippets with PrismJS. Other new components will be introduced over the coming months.

Core Unlocked Package Changes

New LogEntry__c Lighting Web Components (LWC)

• logEntryMetadataViewer - Added a new component built specifically for the LogEntry__c object's record page. This LWC

New Helper Lighting Web Components (LWCs)

• loggerCodeViewer - Added a new helper UI component that uses Prism JS to provide some very nice syntax highlighting & line numbers for displaying blocks of JSON and Apex code
• loggerPageSection - Added a new helper UI component that provides a reusable way of implementing the lightning design system's "expandable section" component bluprint to mimic the functionality that the platform uses for native page layout sections

Updated Lighting Web Components (LWCs)

• loggerHomeHeader - Updated to use the new helper LWC loggerPageSection to provide collapsible page sections in the View Environment Details modal
• loggerSettings - Updated to use the new helper LWC loggerPageSection to provide collapsible page sections in the New/Edit settings modal
• logViewer - Updated to use the new helper LWC loggerCodeViewer to display the Log__c record's JSON data

New LogEntryEvent__e Platform Event Fields

• ExceptionLocation__c
• ExceptionSourceActionName__c
• ExceptionSourceApiName__c
• ExceptionSourceMetadataType__c
• OriginSourceActionName__c
• OriginSourceApiName__c
• OriginSourceMetadataType__c

New LogEntry__c Fields

The 3 permission sets LoggerLogViewer, and LoggerEndUser have been updated to have the relevant access to these new fields

• 16 New 'Exception Source' fields
  • ExceptionLocation__c - this also includes a custom index, and is equivalent to the existing field OriginLocation__c.
  • ExceptionSourceActionName__c
  • ExceptionSourceApiName__c
  • ExceptionSourceApiVersion__c
  • ExceptionSourceCreatedById__c
  • ExceptionSourceCreatedByLink__c
  • ExceptionSourceCreatedByUsername__c
  • ExceptionSourceCreatedDate__c
  • ExceptionSourceId__c
  • ExceptionSourceLastModifiedById__c
  • ExceptionSourceLastModifiedByLink__c
  • `Exce...

v4.13.0 - Spring '24 Release

Managed Package Release - v4.13.0

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

• The v4.13.0 milestone to see all of the issues & pull requests that are included in the this release.
• The diff between v4.12.0 and v4.13.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: this release now provides the managed package with the ability to log in lightning components! 🥳🎉 This functionality has been available in the unlocked package since v4.6.4, but has been unavailable in the managed package... until now!

• Using the Nebula namespace, you can import the included logger LWC into your own LWC and log what's happening in the frontend:

  import { createLogger } from 'Nebula/logger';
  
  export default class LoggerLWCDemo extends LightningElement {
    logger;
    
    async connectedCallback() {
      this.logger = await createLogger();
      this.logger.info('Hello, world');
      this.logger.saveLog();
    }
  }

Thanks so much to @jamessimone for all of the help working on the logger LWC this release! 🥳

Core Unlocked Package Changes - v4.13.0

Spring '24 Release Upgrade

• Bumped all metadata to API v60.0 (Spring '24 release)
• Optimization & cleanup - Switched to using the new standard class System.UUID, instead of my custom UUID class. The new system class is soooo much faster.

logger LWC Bugfixes & Improvements + Enabled logger LWC in the Managed Package

• Worked with @jamessimone to fix #615 by optimizing how logger LWC loads user settings async (as well as several other optimizations throughout the LWC). The component should now log & save entries correctly, but developers need to either use await or chain .then() when calling createLogger().

  Here is an example of using await

  import { createLogger } from 'c/logger';
  
  export default class LoggerLWCDemo extends LightningElement {
    logger;
    
    async connectedCallback() {
      this.logger = await createLogger();
      this.logger.info('Hello, world');
      this.logger.saveLog();
    }
  }

  This example uses .then() in connectedCallback() (instead of await). Additionally, this example shows renderedCallback() using a truthy check on logger to ensure it's been initialized before trying to use it.

  import { createLogger } from 'c/logger';
  
  export default class LoggerLWCDemo extends LightningElement {
    logger;
    
    connectedCallback() {
      createLogger().then(async logger => {
        this.logger = logger;
        this.logger.info('Hello, world');
        await this.logger.saveLog();
      });
    }
  
   // and maybe even ...
    renderedCallback() {
      // this.logger may not be defined for initial renderings
      // you can either use a guard clause:
      if (this.logger) {
        this.logger.info('Some info about a re-rendering');
      }
      // or safe navigation:
      this.logger?.info('Some info about a re-rendering');
    }
  }

• Fixed #533 by updating logger.js-meta.xml so the isExposed node is set to true - this change makes the logger LWC available to use in the managed package for JavaScript logging. You can import it using the Nebula namespace.

Bugfixes

• Fixed an issue in LoggerDataStore where not all string fields were truncated for platform events. This functionality was originally introduced in v4.12.6
  • Also optimized how the code looks for string fields to truncate to reduce some unnecessary looping
• Fixed an issue with the optional Status API integration (used to retrieve additional details about the current org's Salesforce instance) - Updated LogManagementDataSelector to always return null in getCachedRecentLogWithApiReleaseDetails() when LoggerParameter.CALL_STATUS_API is false
  • In previous versions, this method would still query the Log__c object, even if the optional Status API integration was disabled. But when the callout is disabled, this query will never be able to find a match, because the relevant fields haven't been populated by the callout. And in orgs with large data volume (LDV) of logging data, the condition ApiReleaseNumber__c != NULL is a very expensive query operation.
  • This change will now skip the unnecessary (and sometimes expensive) SOQL query when the integration is disabled
• Fixed #624 by commenting out a flappy test in RelatedLogEntriesController_Tests that's been frequently failing due to ongoing platform issues with SOSL. It throws an uncatchable UnexpectedException due to Salesforce platform issues, resulting in (apparently) several pipelines failures for multiple companies that use Nebula Logger in their CI/CD jobs 😢
  • "Fixed" ¯\(ツ)/¯ - The functionality being tested has not changed in a few years, so commenting-out the test for now seems safe, and should prevent unnecessary pipeline failures for anyone that's been impacted by this problem.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.9...v4.13.0

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

Core Managed Package - Nebula namespace

Full Changelog: v4.12.0...v4.13.0

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

Added RestRequest and RestResponse Logging

Thanks to @diegocomi for suggesting this enhancement!

Core Unlocked Package Changes

Added logging support for instances of RestRequest and RestResponse

• Resolved #514 (suggested by @diegocomi) in PR #613 by introducing new features & fields to support logging instances of System.RestRequest and System.RestResponse that are used for Apex REST services:

  • Added 2 new global instance methods in LogEntryBuilder to provide a way to log instances of System.RestRequest and System.RestResponse:

    1. global LogEntryEventBuilder setRestRequestDetails(System.RestRequest request);
    2. global LogEntryEventBuilder setRestResponseDetails(System.RestResponse response);

  • Added 2 new LoggerParameter__mdt records to control logging of request & response headers when using the new builder methods. These LoggerParameter__mdt records are equivalent to the record StoreHttpResponseHeaderValues (introduced in Nebula Logger v4.11.8) for System.HttpResponse logging:

    1. StoreRestRequestHeaderValues - this metadata records controls if the request's header values are stored in new fields LogEntryEvent__e.RestRequestHeaders__c and LogEntryEvent__e.RestrequestHeaders__c. By default, it's enabled.
    2. StoreRestResponseHeaderValues - this metadata records controls if the response's header values are stored in new fields LogEntryEvent__e.RestResponseHeaders__c and LogEntryEvent__e.RestResponseHeaders__c. By default, it's enabled.

  • Added 9 new fields for System.RestRequest data on LogEntryEvent__e platform event

    1. LogEntryEvent__e.RestRequestBodyMasked__c
    2. LogEntryEvent__e.RestRequestBody__c
    3. LogEntryEvent__e.RestRequestHeaderKeys__c
    4. LogEntryEvent__e.RestRequestHeaders__c
    5. LogEntryEvent__e.RestRequestMethod__c
    6. LogEntryEvent__e.RestRequestParameters__c
    7. LogEntryEvent__e.RestRequestRemoteAddress__c
    8. LogEntryEvent__e.RestRequestResourcePath__c
    9. LogEntryEvent__e.RestRequestUri__c

  • Added 5 new fields for System.RestResponse data on LogEntryEvent__e platform event

    1. LogEntryEvent__e.RestResponseBodyMasked__c
    2. LogEntryEvent__e.RestResponseBody__c
    3. LogEntryEvent__e.RestResponseHeaderKeys__c
    4. LogEntryEvent__e.RestResponseHeaders__c
    5. LogEntryEvent__e.RestResponseStatusCode__c

  • Added 12 new fields for System.RestResponse data on LogEntry__c custom object

    1. LogEntry__c.HasRestRequestBody__c
    2. LogEntry__c.HasRestRequestHeaderKeys__c
    3. LogEntry__c.HasRestRequestHeaders__c
    4. LogEntry__c.RestRequestBody__c
    5. LogEntry__c.RestRequestBodyMasked__c
    6. LogEntry__c.RestRequestHeaderKeys__c
    7. LogEntry__c.RestRequestHeaders__c
    8. LogEntry__c.RestRequestMethod__c
    9. LogEntry__c.RestRequestParameters__c
    10. LogEntry__c.RestRequestRemoteAddress__c
    11. LogEntry__c.RestRequestResourcePath__c
    12. LogEntry__c.RestRequestUri__c

  • Added 8 new fields for System.RestResponse data on LogEntry__c custom object

    1. LogEntry__c.HasRestResponseBody__c
    2. LogEntry__c.HasRestResponseHeaderKeys__c
    3. LogEntry__c.HasRestResponseHeaders__c
    4. LogEntry__c.RestResponseBodyMasked__c
    5. LogEntry__c.RestResponseBody__c
    6. LogEntry__c.RestResponseHeaderKeys__c
    7. LogEntry__c.RestResponseHeaders__c
    8. LogEntry__c.RestResponseStatusCode__c

  • Updated permission sets LoggerAdmin, LoggerLogViewer, and LoggerEndUser to add access to the new custom fields on LogEntry__c

  • Add 2 new sections on LogEntryRecordPage flexipage (shown in the screenshot below)

    • Apex REST Service Request section shows the corresponding fields for RestRequest data (when populated)
    • Apex REST Service Response section shows the corresponding fields for RestResponse data (when populated)

  • Renamed 2 existing sections on LogEntryRecordPage flexipage to help avoid confusion with the 2 new sections Apex Rest Service Request and Apex REST Service Response

    • HTTP Request is now HTTP Callout Request
    • HTTP Response is now HTTP Callout Response

    

Reduced the Max Length of Several Existing Long Textarea Fields

As Nebula Logger's data model continues to grow, the per-object limit for long textarea fields becomes increasingly important to consider. To compensate for this limit, and to better reflect the amount of data typically stored in these fields, several older fields have been updated to reduce their max length:

• LogEntryEvent__e.ExceptionMessage__c: 131,072 limit reduced to 5,000
• LogEntryEvent__e.ExceptionStackTrace__c: 131,072 limit reduced to 5,000
• LogEntryEvent__e.StackTrace__c: 131,072 limit reduced to 5,000
• LogEntryEvent__e.Topics__c (deprecated/no longer used): 131,072 limit reduced to 256
• LogEntry__c.ExceptionMessage__c: 131,072 limit reduced to 5,000
• LogEntry__c.ExceptionStackTrace__c: 131,072 limit reduced to 5,000
• LogEntry__c.FlowDescription__c: 131,072 limit reduced to 5,000
• LogEntry__c.StackTrace__c: 131,072 limit reduced to 5,000

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.8...v4.12.9

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

Bugfix: Improved Conditional Visibility for 'HTTP Response' Page Section

Core Unlocked Package Changes

Improved conditional visibility for 'HTTP Response' page section

• Fixed #616 (originally discussed in #586) by updating the conditional visibility rules on the flexipage LogEntryRecordPage. Now, the 'HTTP Response' section will show up if any of these 3 conditions are true:

  • HttpResponseStatus__c != null (existing check)
  • HasHttpResponseBody__c == true
  • HasHttpResponseHeaderKeys__c == true

• Fixed some test failures in ComponentLogger_Tests that occurred when running in a namespaced context

• Added the new-ish Analytics standard tab to the navigation items in the LoggerConsole app. This tab is generally available (GA) as of Salesforce's Summer '23 release.

  

Pipeline Changes

• Upgraded most of the devDependencies in package.json, including the sf cli
• Hopefully fixed package generation for the managed package by including an empty copy of Admin.profile-meta.xml ಥ_ಥ
• Updated both sfdx-project.json files (1 for the unlocked package & 1 for the managed package) to use the new flag "scopeProfiles": true

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.7...v4.12.8

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