Skip to content

Releases: jongpie/NebulaLogger

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

Bugfix for Lightning Component Entries Not Always Saving

24 Oct 01:51
@jongpie jongpie
v4.11.12
b140e72
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
Bugfix for Lightning Component Entries Not Always Saving

Core Unlocked Package Changes

logger LWC Changes

  • @jamessimone fixed #518 by updating logger LWC to defer calling console.log() and to defer saving log entries until after LoggerSettings__c data has been loaded for the current user.
    • Previously, logging in some lifecycle events, such as connectedCallback(), would unintentionally (and inconsistently) skip some log entries, resulting in data loss of some logging data. Thanks to @shuylern for reporting this issue!

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.11...v4.11.12

Contributors

jamessimone and shuylern
Assets 2
Loading
0 Join discussion

Reduced SingleEmailMessage limit usage

15 Oct 02:22
@jongpie jongpie
v4.11.11
77fe275
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
Reduced SingleEmailMessage limit usage

Core Unlocked Package Changes

LoggerEmailSender Changes

  • Fixed #369 by changing how failure emails are sent to the 'Apex Exception Email' recipients (shown in the screenshot below, configurable under Setup --> Apex Exception Email)
    • Previously, the user ID (ApexEmailNotification.UserId) of Salesforce users configured as recipients (labeled as '1' in the screenshot below) was passed to the instance method Messaging.SingleEmailMessage.setToAddresses(), resulting in the email counting as an email to an external email address, which has an org daily limit. You can check your org's limit using this Apex snippet: System.debug(OrgLimits.getMap().get('SingleEmail'));
    • Now, the user ID (ApexEmailNotification.UserId) is passed to the instance method Messaging.SingleEmailMessage.setTargetObjectId(). Using setTargetObjectId() to send emails to users does not count towards the org's daily limit
    • External email addresses (labeled as '2' in the screenshot below, configured under Setup --> Apex Exception Email) will still count towards the org's daily email limit

image

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.10...v4.11.11

Assets 2
Loading
0 Join discussion

Dynamic field visibility for LogEntry__c HTTP response header fields

13 Oct 01:11
@jongpie jongpie
v4.11.10
f2fe85c
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
Dynamic field visibility for LogEntry__c HTTP response header fields

Core Unlocked Package Changes

New LogEntry__c checkbox fields

  • Added new checkbox fields on LogEntry__c for each long textarea fields that didn't previously have an equivalent checkbox field. Note: these new fields will be inaccurate for existing LogEntry__c records (but correct on new records).
    • HasDatabaseResultJson__c - set based on logEntry.DatabaseResultJson__c != null
    • HasHttpRequestBody__c - set based on logEntry.HttpRequestBody__c != null
    • HasHttpResponseBody__c - set based on logEntry.HttpResponseBody__c != null
    • HasHttpResponseHeaderKeys__c - set based on logEntry.HttpResponseHeaderKeys__c != null
    • HasHttpResponseHeaders__c - set based on logEntry.HttpResponseHeaders__c != null
  • Code cleanup: rewrote several existing tests in LogEntryHandler_Tests to be true unit tests that do not rely on DML

Dynamic field visibility for LogEntry__c HTTP response header field

  • Resolved #566 by updating LogEntryRecordPage.flexipage-meta.xml to have conditional visibility for the fields HttpResponseHeaderKeys__c and HttpResponseHeaders__c, based on the new checkbox field HasHttpResponseHeaders__c

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.9...v4.11.10

Assets 2
Loading
0 Join discussion

Bugfix: Usernames on Log Entry Summary Report show up in an HTML Tag

11 Oct 03:50
@jongpie jongpie
v4.11.9
4ede2fb
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
Bugfix: Usernames on Log Entry Summary Report show up in an HTML Tag

Thanks so much to @JMercie for yet another amazing contribution (PR #567), and thanks so much to @Senay-Ersen for reporting this issue (issue #543)!

Core Unlocked Package Changes

Bugfix: Usernames on Log Entry Summary Report show up in an HTML Tag

Resolved #543 with a couple of new formula fields + report update

  • Added new formula fields Log__c.LoggedByUsernameText__c and LogEntry__c.LoggedByUsernameText__c that display only the text of the logging user's username (compared to the existing fields LoggedByUsernameLink__c that display the logging user's username as a clickable link)
  • Updated report LogEntrySummary to use the new field Log__c.LoggedByUsernameText__c (instead of the problematic-in-reports formula field Log__c.LoggedByUsernameLink__c)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.8...v4.11.9

Contributors

JMercie and Senay-Ersen
Assets 2
Loading
0 Join discussion

Store HttpResponse header values

06 Oct 17:43
@jongpie jongpie
v4.11.8
d1ed36e
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
Store HttpResponse header values

Thanks so much to @TrangOul for suggesting this enhancement, providing Apex code snippets for the implementation, and helping with code review!

Core Unlocked Package Changes

New Feature: Store HttpResponse Header Values

  • Resolved #561 (reported by @TrangOul) by adding new fields LogEntryEvent__e.HttpResponseHeaders__c and LogEntry__c.HttpResponseHeaders__c that store the full key-value pair for each header set on the logged instance of System.HttpResponse. These fields are now automatically set when using the instance method LogEntryEventBuilder.setHttpResponseDetails(System.HttpResponse).

    • Based on the great suggestion from @TrangOul, each header key-value pair is stored in the format Header: value to match the (HTTP standard). A \n line break is used as a delimiter between each header when there are multiple headers.
    • For orgs that do not want to store the header values (either due to security concerns with storing this information, or other concerns), you can disable this functionality org-wide by updating the new LoggerParameter__mdt record StoreHttpResponseHeaderValues to false. By default, this feature is enabled/set to true
    • The existing fields LogEntryEvent__e.HttpResponseHeaderKeys__c and LogEntry__c.HttpResponseHeaderKeys__c will continue to be populated. These fields store only the header keys, not the header values, and some orgs have existing tests & logic that rely on checking the logged keys. These fields are always populated for instances of System.HttpResponse, regardless of the configuration of the new LoggerParameter__mdt record StoreHttpResponseHeaderValues.

  • Updated permission sets LoggerAdmin and LoggerLogViewer to have read access to the new field LogEntry__c.HttpResponseHeaders__c.

    • The permission set LoggerEndUser intentionally does not have access to this field (or any other fields related to HttpResponse or HttpRequest).

  • Added new field LogEntry__c.HttpResponseHeaders__c to the FlexiPage LogEntryRecordPage. This field is shown in addition to the existing field LogEntry__c.HttpResponseHeaderKeys__c, shown in the (massive 😅) screenshot below

    image

Updated Internal Coding Conventions for Apex if Statements

  • Updated ~300 if statements throughout the codebase to simplify checking Booleans from if(condition == true) to just if(condition). A few existing Booleans were also updated to have a default value to avoid issues with null values.
    • This (hopefully) shouldn't impact any functionality in Nebula Logger - the goal of this change is purely to update the coding style used within the codebase to be a bit more concise, based on some feedback received over the last year or so, including a discussion last year with @rmccu in #383 and PR comment from @TrangOul.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.7...v4.11.8

Contributors

TrangOul and rmccu
Assets 2
Loading
0 Join discussion

Bugfix For Save Failures When Using Tagging + SYNCHRONOUS_DML

04 Oct 17:06
@jongpie jongpie
v4.11.7
a5a960f
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
Bugfix For Save Failures When Using Tagging + SYNCHRONOUS_DML

This release fixes issue #526 reported by @cbcruz74 (in discussion #511) - previously, using a combination of Nebula Logger's tagging system + the save method SYNCHRONOUS_DML (shown in the snippet below) would fail, preventing some logging data from being saved.

Logger.info('hello').addTag('world');
Logger.saveLog(Logger.SaveMethod.SYNCHRONOUS_DML);

This was caused by code that relied on the standard field LogEntryEvent__e.EventUuid - part of the tagging system internally used this field to track & create related LogEntryTag__c records for new LogEntry__c records. When using the save method SYNCHRONOUS_DML, the EventUuid is null, which broke the LogEntryTag__c record creation.

A huge thank you to both @JMercie for working on this release (PR #539), and to @cbcruz74 for reporting the issue!

Core Unlocked Package Changes

New Field LogEntry__c.UniqueId__c

  • Added new unique external ID field LogEntry__c.UniqueId__c - this field is now used to upsert LogEntry__c records
    • This is populated with a composite key consisting of the fields LogEntryEvent__e.TransactionId__c and LogEntryEvent__e.TransactionEntryNumber__c. The combination of these fields has been implicitly a unique composite key ever since the field TransactionEntryNumber__c was introduced in v4.4.0, but it wasn't being stored anywhere - now it is, in the new UniqueId__c field
  • Added the new UniqueId__c field to the FlexiPage LogEntryRecordPage
  • Added the new UniqueId__c field to the permission sets LoggerAdmin, LoggerLogViewer, and LoggerEndUser

Bugfix For Save Failures When Using Tagging + SYNCHRONOUS_DML

  • Updated LogEntryEventHandler class to leverage the new field LogEntry__c.UniqueId__c for upserting & internally tracking LogEntry__c records and their associated LogEntryTag__c records (instead of leveraging the standard field LogEntryEvent__e.EventUuid)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.6...v4.11.7

Contributors

cbcruz74 and JMercie
Assets 2
Loading
0 Join discussion

New Method Logger.setAsyncContext()

28 Sep 03:17
@jongpie jongpie
v4.11.6
13f2faa
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
New Method Logger.setAsyncContext()

This release introduces a new method & fields to further help with monitoring & troubleshooting of async jobs, using the platform-provided async context interfaces:

  1. Database.BatchableContext
  2. System.FinalizerContext
  3. System.QueueableContext
  4. System.SchedulableContext

The new features in this release can be used either in place of, or in addition to, Nebula Logger's existing method, Logger.setParentTransactionId(), to help with identifying logs from related asynchronous transactions.

Core Unlocked Package Changes

New Method Logger.setAsyncContext()

  • Added new global method Logger.setAsyncContext(). There are 4 overloads - 1 for each of the platform-provided interfaces: 
     void setAsyncContext(Database.BatchableContext batchableContext) {}
 void setAsyncContext(System.FinalizerContext finalizerContext) {}
 void setAsyncContext(System.QueueableContext queueableContext) {}
 void setAsyncContext(System.SchedulableContext schedulableContext) {}

New Fields on LogEntryEvent__e and Log__c

  • Added new fields on LogEntryEvent__e and Log__c that are set by using Logger.setAsyncContext()
    New Fields Description
    LogEntryEvent__e.AsyncContextType__c and Log__c.AsyncContextType__c The interface of the platform-provided context. Current values are Database.BatchableContext, System.FinalizerContext, System.QueueableContext, and System.SchedulableContext.
    LogEntryEvent__e.AsyncContextParentJobId__c and Log__c.AsyncContextParentJobId__c The ID of the parent job (Schema.AsyncApexJob) that initiated the async transaction. Used for Database.Batchable, System.FinalizerContext, and System.QueueableContext.
    LogEntryEvent__e.AsyncContextChildJobId__c and Log__c.AsyncContextChildJobId__c The ID of the child job (Schema.AsyncApexJob) that initiated the async transaction. Used for Database.Batchable.
    LogEntryEvent__e.AsyncContextTriggerId__c and Log__c.AsyncContextTriggerId__c The ID of the cron trigger (Schema.CronTrigger) that initiated the async transaction.
  • Updated FlexiPage LogRecordPage to conditionally show a new page section, "Async Context Details", which also conditionally shows the 4 new fields, shown in the screenshot below (in the red box)
    image
  • Updated several async classes (including LogBatchPurger and LogBatchPurgeScheduler) to leverage the new method Logger.setAsyncContext()

Internal Code Cleanup

  • Eliminated the helper method LoggerMockDataCreator.createBatchableContext() - the underlying mock batchable context class, as well as some new similar mocks for Finalizer, Queueable, and Schedulable`, are now public and can be instantiated directly
    • Having the extra static methods was adding a lot of unnecessary complication & redundant code to expose static methods for each constructor

Pipeline Changes

  • Upgraded sf cli (again) to try to resolve some packaging issues in the pipeline (again)
  • Updated build.yml to output sf version to help with troubleshooting any future pipeline issues

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.5...v4.11.6

Assets 2
Loading
0 Join discussion

Added Custom Index for Log Retention Date

20 Sep 16:53
@jongpie jongpie
v4.11.5
d4aeb00
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
Added Custom Index for Log Retention Date

Core Unlocked Package Changes

Added Custom Index for Log__c.LogRetentionDate__c

  • Added a custom index for the field Log__c.LogRetentionDate__c. This should help speed up the LogBatchPurger batch job (among other things that use this field, such as list views, etc.) in orgs with large data volumes (LDV).

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.4...v4.11.5

Assets 2
Loading
0 Join discussion

Removed Chatter dependencies

20 Sep 14:19
@jongpie jongpie
v4.11.4
fb6cd3e
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
Removed Chatter dependencies

For years, Nebula Logger has leveraged Chatter's field feed tracking functionality to automatically create Chatter posts for new Log__c and LogEntry__c records. In Salesforce, this can be done in 2 steps:

  1. Enabling feeds on a custom object, like Log__c
  2. Enabling feed tracking on a field within that object, such as Log__c.LoggedBy__c

When deploying metadata/installing packages, Salesforce will gracefully handle orgs with Chatter disabled:

  • When Chatter is enabled in the org, the trackFeedHistory node in field metadata is used to automatically enable Chatter's feed tracking in the appropriate fields
  • When Chatter is disabled in the org, the fields still deploy & the trackFeedHistory node is ignored/the deployment completes successfully

However, several of the App Builder pages (FlexiPage metadata) in Nebula Logger have been using the standard Chatter components to display the record's Chatter activity. Using these standard components has created a hard dependency on having Chatter enabled - orgs with Chatter disabled have been blocked from installing Nebula Logger.

Given that Nebula Logger's usage of Chatter is very simple (it only has field feed tracking enabled as a convenience - there is no other functionality in Nebula Logger that relies on Chatter), having Chatter disabled should not prevent orgs from utilizing Nebula Logger. As a compromise, this release removes the Chatter components from Nebula Logger's UI, but feed data is still automatically tracked on the backend in orgs that have Chatter enabled.

Core Unlocked Package Changes

Removed Chatter dependencies

  • Disabled Chatter in base scratch org file config/scratch-orgs/base-scratch-def.json to help implicitly test in the pipeline that Chatter is not required to deploy/install Nebula Logger
    • The experience cloud scratch org file config/scratch-orgs/experience-cloud-scratch-def.json will continue to have Chatter enabled to help test that Chatter being enabled doesn't cause problems either 😅
  • Removed all Chatter components in FlexiPage metadata to remove a dependency on Chatter being enabled in orgs - Chatter is no longer required 🥳
    • No changes have been made to the objects & fields that have Chatter feed tracking enabled (<trackFeedHistory>true</trackFeedHistory> in the field XML)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.11.3...v4.11.4

Assets 2
Loading
0 Join discussion