Skip to content

Releases: jongpie/NebulaLogger

Added RestRequest and RestResponse Logging

02 Feb 04:43
@jongpie jongpie
v4.12.9
f602f90
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
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

      image

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

Contributors

diegocomi
Assets 2
Loading
2 Join discussion

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

29 Jan 03:40
@jongpie jongpie
v4.12.8
21e02ac
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
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.

    image

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

Assets 2
Loading
0 Join discussion

Bugfix for Broken LWC Stack Trace Parsing

28 Jan 19:14
@jongpie jongpie
v4.12.7
d452edd
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Bugfix for Broken LWC Stack Trace Parsing

Core Unlocked Package Changes

Fixed Stack Trace Parsing for Lightning Web Components (LWCs)

  • Fixed #346 again (previously fixed in v4.8.0) and partially fixed #615 by updating ComponentLogger.cls so it handles recent-ish changes to the format of stack traces in LWCs.
    • Previously, this bug would have resulted in fields like LogEntry__c.OriginLocation__c and LogEntry__c.StackTrace__c being incorrectly set to null for log entries generated via LWCs using the logger LWC.
    • Also updated ComponentLogger_Tests to validate that the logic in ComponentLogger handles different variations of LWC stack traces, so hopefully there aren't future regression issues with this functionality

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.6...v4.12.7

Assets 2
Loading
0 Join discussion

Bugfix: Added automatic string truncation for LogEntryEvent__e fields

22 Jan 18:22
@jongpie jongpie
v4.12.6
50449ff
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Bugfix: Added automatic string truncation for LogEntryEvent__e fields

Thanks to @TrangOul, @BastienRaoul, and @Damecek for reporting these issues!

Core Unlocked Package Changes

Automatic String Field Truncation for LogEntryEvent__e Platform Event Records

  • Fixed #589 (reported by @BastienRaoul) and fixed #592 (reported by @Damecek) by updating LoggerDataStore.EventBus to support using Database.DmlOptions for enabling automatic field truncation on platform events, using some custom truncation logic (platform events do not normally support using Database.DmlOptions).
    • Logger now passes an instance of Database.DmlOptions with AllowFieldTruncation == true when publishing LogEntryEvent__e records

Data Masking Optimizations

  • Fixed #587 (reported by @TrangOul) by updating LogEntryEventBuilder to automatically truncate any provided String parameters before calling applyDataMaskRules(). This truncation is somewhat redundant with the string truncation now performed in LoggerDataStore - but the use of data masking on certain String parameters necessitates an initial truncation before any other parsing occurs
    • Also removed several internal uses of truncateFieldValue() in LogEntryEventBuilder, now that LoggerDataStore will automatically truncate platform event string fields

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.5...v4.12.6

Contributors

TrangOul, BastienRaoul, and Damecek
Assets 2
Loading
0 Join discussion

Bugfix: Name Shadowing Issues for Several Schema Apex Classes

21 Jan 22:38
@jongpie jongpie
v4.12.5
579286d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Bugfix: Name Shadowing Issues for Several Schema Apex Classes

Thanks to @amp42 for reporting this bug!

Core Unlocked Package Changes

Switched Using Fully-Qualified Class Names in the Schema Namespace

  • Fixed #584 (reported by @amp42) by switching to using fully-qualified Apex class references to several classes in the Schema namespace, like Schema.User, to avoid collision issues in orgs that use name-shadowing classes. These class references are now fully-qualified throughout the codebase. This is the same concept & approach as the changes made in v4.9.0, v4.9.4, and v4.9.6 to fully-qualify references to classes & enums in the System namespace

    • Schema.Account (these references are only used for tests & sample recipes, not in Nebula Logger's core code)
    • Schema.AuthSession
    • Schema.LoginHistory
    • Schema.Network
    • Schema.Organization
    • Schema.Profile
    • Schema.Topic
    • Schema.TopicAssignment
    • Schema.User

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.4...v4.12.5

Contributors

amp42
Assets 2
Loading
0 Join discussion

Bugfix: Child Log__c Records Not Properly Linked to Parent Log__c Records

21 Jan 18:00
@jongpie jongpie
v4.12.4
2735d4e
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Bugfix: Child Log__c Records Not Properly Linked to Parent Log__c Records

Thanks to @ctcforce for reporting this bug!

Core Unlocked Package Changes

Logger Apex Class Changes

  • Resolved #585 (reported by @ctcforce) by updating LogHandler to handle some scenarios where a Log__c record would have a value in ParentLogTransactionId__c but a null value in ParentLog__c. Now in an AFTER_INSERT context, LogHandler requeries any potentially orphaned child Log__c records and links them to their parent Log__c records. Please note that this does not fix any existing problematic data in your org - it only prevents new problematic records from being created. To fix existing data in an org, you can run this anonymous Apex script:

    List<Log__c> unlinkedChildLogs = [
  SELECT Id, ParentLogTransactionId__c
  FROM Log__c
  WHERE ParentLogTransactionId__c != NULL AND ParentLog__c = NULL
];
List<String> parentLogTransactionIds = new List<String>();
for (Log__c unlinkedChildLog : unlinkedChildLogs) {
    parentLogTransactionIds.add(unlinkedChildLog.ParentLogTransactionId__c);
}

Map<String, Log__c> parentLogTransactionIdToLog = new Map<String, Log__c>();
for (Log__c parentLog : [SELECT Id, TransactionId__c FROM Log__c WHERE TransactionId__c IN :parentLogTransactionIds]) {
    parentLogTransactionIdToLog.put(parentLog.TransactionId__c, parentLog);
}

for (Log__c unlinkedChildLog : unlinkedChildLogs) {
    unlinkedChildLog.ParentLog__c = parentLogTransactionIdToLog.get(unlinkedChildLog.ParentLogTransactionId__c)?.Id;
}
update unlinkedChildLogs;

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.3...v4.12.4

Contributors

ctcforce
Assets 2
Loading
0 Join discussion

Bugfix for UserInfo.getSessionId() Exception

21 Jan 16:14
@jongpie jongpie
v4.12.3
b0bec13
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Bugfix for UserInfo.getSessionId() Exception

Thanks to @dvanlooy for reporting this bug!

Core Unlocked Package Changes

Logger Apex Class Changes

  • Resolved #598 (reported by @dvanlooy) by adding a try-catch block around the usage of System.UserInfo.getSessionId() - in some situations, such as a connected app using JWT, calling this method will throw an exception
  • Optimized how Logger.TRANSACTION_QUIDDITY is loaded so it doesn't repeatedly try to load in transactions where there isn't an active quiddity

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.2...v4.12.3

Contributors

dvanlooy
Assets 2
Loading
0 Join discussion

Automatically Select a Default Field Set in LWC relatedLogEntries

20 Jan 17:13
@jongpie jongpie
v4.12.2
c1aeecd
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Automatically Select a Default Field Set in LWC relatedLogEntries

Thanks to @shreyas-girjapure for suggesting this enhancement!

Core Unlocked Package Changes

relatedLogEntries LWC Changes

  • Resolved #596 by automatically setting a default LogEntry__c field set when adding the LWC relatedLogEntries in App Builder. Previously, admins & developers had to manually select a field set first.

    image

  • Added new LoggerParameter__mdt record DefaultLogEntryRelatedListFieldSet to control which field set is automatically selected as the default. If you have your own field set that you would like to be automatically selected in App Builder, simply update this record with the API name of your own field set.

    image

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.1...v4.12.2

Contributors

shreyas-girjapure
Assets 2
Loading
0 Join discussion

Improved Error Emails

18 Jan 15:37
@jongpie jongpie
v4.12.1
b24d1f5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
Improved Error Emails

Thanks so much to @alanjaouen for this release!

Core Unlocked Package Changes

Error Email Notification Changes

  • When Nebula Logger has an error (due to a bug, platform limits, etc), an error email is automatically sent to admins using the Apex class LoggerEmailSender - these emails previously did not contain enough information to troubleshoot some issues. @alanjaouen reported this in issue #590 and fixed it in PR #591 by updating LoggerEmailSender to include the list of relevant fields for any DML failures that can occur (such as creating Log__c and LogEntry__c records).

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.12.0...v4.12.1

Contributors

alanjaouen
Assets 2
Loading
0 Join discussion

v4.12.0 - Winter '24 Release

09 Nov 03:45
@jongpie jongpie
v4.12.0
53af967
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v4.12.0 - Winter '24 Release

Managed Package Release - v4.12.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.11.0 and v4.12.0 by reviewing:

  • The v4.12.0 milestone to see all of the issues & pull requests that are included in the this release.
  • The diff between v4.11.0 and v4.12.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 includes, for the first time, CustomIndex metadata in the managed package. This metadata has already been used in the unlocked packages since v4.10.5, but was previously excluded in the v4.11.0 release of the managed package due to the metadata type being relatively new. At the moment, there are 2 custom indexes included:

  1. Nebula__Log__c.Nebula__LogRetentionDate__c - initially introduced in the unlocked package in v4.11.5
  2. Nebula__LogEntry__c.Nebula__OriginLocation__c - initially introduced in the unlocked package in v4.10.5

These new custom indexes should improve the performance of other metadata that filters on these fields, such as SOQL queries, reports, list views, etc.

Core Unlocked Package Changes - v4.12.0

Winter '24 Release Upgrade

  • Updated all metadata to API v59.0 (Winter '24 release)
  • Switched from using Url.getSalesforceBaseUrl() to Url.getOrgDomainUrl() - Url.getSalesforceBaseUrl() was deprecated in v59.0

Enhancements

  • Resolved #571 by adding new formula fields Log__c.TransactionScenarioText__c and LogEntry__c.EntryScenarioText__c that display the corresponding scenario names, stored either in lookups or in text fields. These fields help to simplify reporting & automation that rely on the text value of a scenario's name.

Bugfixes

  • Fixed #576 by switching to using a Map<String, SObject> internally + replacing null with '' empty string when logging Map<Id, SObject>, and fixed an unreported issue with record stripping not being applied to Map<Id, SObject>

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.12...v4.12.0

Core Managed Package - Nebula namespace

Full Changelog: v4.11.0...v4.12.0

Assets 2
Loading
0 Join discussion