Releases: jongpie/NebulaLogger
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 existingLogEntry__c
records (but correct on new records).HasDatabaseResultJson__c
- set based onlogEntry.DatabaseResultJson__c != null
HasHttpRequestBody__c
- set based onlogEntry.HttpRequestBody__c != null
HasHttpResponseBody__c
- set based onlogEntry.HttpResponseBody__c != null
HasHttpResponseHeaderKeys__c
- set based onlogEntry.HttpResponseHeaderKeys__c != null
HasHttpResponseHeaders__c
- set based onlogEntry.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 fieldsHttpResponseHeaderKeys__c
andHttpResponseHeaders__c
, based on the new checkbox fieldHasHttpResponseHeaders__c
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.9...v4.11.10
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001OigxQAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001OigxQAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001OigxQAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001OigxQAC
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
andLogEntry__c.LoggedByUsernameText__c
that display only the text of the logging user's username (compared to the existing fieldsLoggedByUsernameLink__c
that display the logging user's username as a clickable link) - Updated report
LogEntrySummary
to use the new fieldLog__c.LoggedByUsernameText__c
(instead of the problematic-in-reports formula fieldLog__c.LoggedByUsernameLink__c
)
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.8...v4.11.9
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001OigJQAS
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001OigJQAS
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001OigJQAS
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001OigJQAS
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
andLogEntry__c.HttpResponseHeaders__c
that store the full key-value pair for each header set on the logged instance ofSystem.HttpResponse
. These fields are now automatically set when using the instance methodLogEntryEventBuilder.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
recordStoreHttpResponseHeaderValues
tofalse
. By default, this feature is enabled/set totrue
- The existing fields
LogEntryEvent__e.HttpResponseHeaderKeys__c
andLogEntry__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 ofSystem.HttpResponse
, regardless of the configuration of the newLoggerParameter__mdt
recordStoreHttpResponseHeaderValues
.
- Based on the great suggestion from @TrangOul, each header key-value pair is stored in the format
-
Updated permission sets
LoggerAdmin
andLoggerLogViewer
to haveread
access to the new fieldLogEntry__c.HttpResponseHeaders__c
.- The permission set
LoggerEndUser
intentionally does not have access to this field (or any other fields related toHttpResponse
orHttpRequest
).
- The permission set
-
Added new field
LogEntry__c.HttpResponseHeaders__c
to the FlexiPageLogEntryRecordPage
. This field is shown in addition to the existing fieldLogEntry__c.HttpResponseHeaderKeys__c
, shown in the (massive 😅) screenshot below
Updated Internal Coding Conventions for Apex if
Statements
- Updated ~300
if
statements throughout the codebase to simplify checking Booleans fromif(condition == true)
to justif(condition)
. A few existing Booleans were also updated to have a default value to avoid issues withnull
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
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Oig9QAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Oig9QAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Oig9QAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Oig9QAC
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 upsertLogEntry__c
records- This is populated with a composite key consisting of the fields
LogEntryEvent__e.TransactionId__c
andLogEntryEvent__e.TransactionEntryNumber__c
. The combination of these fields has been implicitly a unique composite key ever since the fieldTransactionEntryNumber__c
was introduced inv4.4.0
, but it wasn't being stored anywhere - now it is, in the newUniqueId__c
field
- This is populated with a composite key consisting of the fields
- Added the new
UniqueId__c
field to the FlexiPageLogEntryRecordPage
- Added the new
UniqueId__c
field to the permission setsLoggerAdmin
,LoggerLogViewer
, andLoggerEndUser
Bugfix For Save Failures When Using Tagging + SYNCHRONOUS_DML
- Updated
LogEntryEventHandler
class to leverage the new fieldLogEntry__c.UniqueId__c
for upserting & internally trackingLogEntry__c
records and their associatedLogEntryTag__c
records (instead of leveraging the standard fieldLogEntryEvent__e.EventUuid
)
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.6...v4.11.7
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZfaQAG
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZfaQAG
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfaQAG
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfaQAG
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:
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
methodLogger.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
andLog__c
that are set by usingLogger.setAsyncContext()
New Fields Description LogEntryEvent__e.AsyncContextType__c
andLog__c.AsyncContextType__c
The interface of the platform-provided context. Current values are Database.BatchableContext
,System.FinalizerContext
,System.QueueableContext
, andSystem.SchedulableContext
.LogEntryEvent__e.AsyncContextParentJobId__c
andLog__c.AsyncContextParentJobId__c
The ID of the parent job ( Schema.AsyncApexJob
) that initiated the async transaction. Used forDatabase.Batchable
,System.FinalizerContext
, andSystem.QueueableContext
.LogEntryEvent__e.AsyncContextChildJobId__c
andLog__c.AsyncContextChildJobId__c
The ID of the child job ( Schema.AsyncApexJob
) that initiated the async transaction. Used forDatabase.Batchable
.LogEntryEvent__e.AsyncContextTriggerId__c
andLog__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)
- Updated several async classes (including
LogBatchPurger
andLogBatchPurgeScheduler
) to leverage the new methodLogger.setAsyncContext()
Internal Code Cleanup
- Eliminated the helper method
LoggerMockDataCreator.createBatchableContext()
- the underlying mock batchable context class, as well as some new similar mocks forFinalizer
,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 outputsf version
to help with troubleshooting any future pipeline issues
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.5...v4.11.6
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZfGQAW
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZfGQAW
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfGQAW
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZfGQAW
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 theLogBatchPurger
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
- SFDX CLI:
sfdx package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZdZQAW
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdZQAW
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdZQAW
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:
- Enabling feeds on a custom object, like
Log__c
- 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 😅
- The experience cloud scratch org file
- 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)
- No changes have been made to the objects & fields that have Chatter feed tracking enabled (
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.3...v4.11.4
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZdPQAW
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZdPQAW
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdPQAW
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZdPQAW
Bugfix for unhandled exception when email limits are reached
Many thanks to @patrick-skamarak for this release!
Core Unlocked Package Changes
Bugfixes
- @patrick-skamarak reported issue #547 and fixed it in PR #548 🥳 This was an issue in the Apex class
LoggerEmailSender
where it would continue to try (and fail) to send email notifications when the org's daily limit forSingleEmail
had been exceeded. Now, it will just skip attempting to send email notifications when the limit has been exceeded.- There is a related open issue, #369, to improve how emails are sent to prevent (or drastically reduce) the usage of the
SingleEmail
limits. This will hopefully be implemented in the coming weeks as part of thev4.12.0
milestone (Winter '24 release.
- There is a related open issue, #369, to improve how emails are sent to prevent (or drastically reduce) the usage of the
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.2...v4.11.3
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001HZd0QAG
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001HZd0QAG
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZd0QAG
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001HZd0QAG
New Logger.exception() methods for Apex developers
Core Unlocked Package Changes
New Logger.exception() methods for Apex developers
This release provides some syntactic sugar for Apex developers when logging exceptions. A common pattern for using Nebula Logger is to log exceptions in try-catch
blocks. Once an exception has been caught, Apex developers have to add 3 lines of code in order to log the exception & re-throw it, as shown below:
try {
insert new Account();
} catch (System.Exception ex) {
Logger.error('something broke 😥', ex);
Logger.saveLog(Logger.SaveMethod.EVENT_BUS);
throw ex;
}
Although 3 lines of code isn't a huge amount of code, it's still tedious to have to repeat the same code in any relevant try-catch
blocks. Now, Apex developers can use the new method overloads Logger.exception()
to consolidate down to 1 line in a catch
block. The end result of the below snippet is identical to the snippet above - both result in a new ERROR
log entry being generated, automatically saved, and then the exception is thrown.
try {
insert new Account();
} catch (System.Exception ex) {
Logger.exception('something broke 😥', ex);
}
The full list of new Logger.exception()
method overloads is shown below. Each of the methods will log an entry with ERROR
logging level, save the log, and then throw the provided exception. Since an exception is always thrown, the method overloads all have a void
return type.
global static void exception(LogMessage logMessage, System.Exception apexException);
global static void exception(LogMessage logMessage, Id recordId, System.Exception apexException);
global static void exception(LogMessage logMessage, SObject record, System.Exception apexException);
global static void exception(LogMessage logMessage, List<SObject> records, System.Exception apexException);
global static void exception(String message, System.Exception apexException);
global static void exception(String message, Id recordId, System.Exception apexException);
global static void exception(String message, SObject record, System.Exception apexException);
global static void exception(String message, List<SObject> records, System.Exception apexException);
Bugfixes
- Bugfix for issue #529 where the optional integration with
api.status.salesforce.com
would cause exceptions in Nebula Logger if the remote site setting was disabled and the callout was still enabled viaLoggerParameter__mdt
recordCallStatusApi
. Now, Nebula Logger internally catches any callout exceptions, which should prevent any downstream issues from occurring.
Apex Test Improvements
- Scope creep: finished a few
TODO
items in the Apex classLogger_Tests
(part of the logger engine layer) so that it's not aware of the log-management layer by rewriting several test methods to remove references toLog__c
andLogEntry__c
. These tests now also use mocks for theSystem.EventBus
class, so they're now much faster 🏎️
Pipeline Enhancements
- @JMercie closed issue #527 by updating Nebula Logger's pipeline & build scripts to use the new
sf
CLI, instead of thesfdx
cli` (PR #532). Thanks to @JMercie for another amazing contribution! 🥳
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.1...v4.11.2
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001TsZAQA0
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001TsZAQA0
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsZAQA0
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsZAQA0
Added the Ability to Throw Fault Exception in Flow Actions
A huge thank you to @JMercie for working on this release, and congratulations on their first-ever open source contribution! (PR #516). And many thanks also to @Sidle for suggesting this great enhancement (issue #489).
Core Unlocked Package Changes
Added the Ability to Throw Fault Exceptions in Flow Actions
This release closes #489 by providing a new option when logging in Flow - when logging a Flow fault message (shown as 1
in the screenshot below), you can now have the invocable action automatically re-throw the encountered exception (shown as 2
in the screenshot below). This provides a great way to still display an error to the user & rollback any other DML in the current transaction, while still saving your logging data.
- Updated all 3 Flow invocable logging actions (Apex classes
FlowLogEntry
,FlowRecordLogEntry
, andFlowCollectionLogEntry
) to have a new optionalBoolean
property,shouldThrowFaultMessageException
. When set totrue
, the provided Flow fault message (using theString
propertyfaultMessage
) will be used to create & throw an instance of the standard exception classSystem.FlowException
- Updated
FlowLogger
to handle throwing the exception for all 3 Flow invocable logging actions
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.0...v4.11.1
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001TsX4QAK
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001TsX4QAK
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsX4QAK
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001TsX4QAK