Releases: jongpie/NebulaLogger
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 updatingComponentLogger.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
andLogEntry__c.StackTrace__c
being incorrectly set tonull
for log entries generated via LWCs using thelogger
LWC. - Also updated
ComponentLogger_Tests
to validate that the logic inComponentLogger
handles different variations of LWC stack traces, so hopefully there aren't future regression issues with this functionality
- Previously, this bug would have resulted in fields like
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.12.6...v4.12.7
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk21QAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk21QAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk21QAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk21QAC
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 usingDatabase.DmlOptions
for enabling automatic field truncation on platform events, using some custom truncation logic (platform events do not normally support usingDatabase.DmlOptions
).Logger
now passes an instance ofDatabase.DmlOptions
withAllowFieldTruncation == true
when publishingLogEntryEvent__e
records
Data Masking Optimizations
- Fixed #587 (reported by @TrangOul) by updating
LogEntryEventBuilder
to automatically truncate any provided String parameters before callingapplyDataMaskRules()
. This truncation is somewhat redundant with the string truncation now performed inLoggerDataStore
- 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()
inLogEntryEventBuilder
, now thatLoggerDataStore
will automatically truncate platform event string fields
- Also removed several internal uses of
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.12.5...v4.12.6
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk5UQAS
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk5UQAS
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5UQAS
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5UQAS
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, likeSchema.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 inv4.9.0
,v4.9.4
, andv4.9.6
to fully-qualify references to classes & enums in theSystem
namespaceSchema.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
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk5PQAS
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk5PQAS
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5PQAS
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5PQAS
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 aLog__c
record would have a value inParentLogTransactionId__c
but anull
value inParentLog__c
. Now in anAFTER_INSERT
context,LogHandler
requeries any potentially orphaned childLog__c
records and links them to their parentLog__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
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk5KQAS
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk5KQAS
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5KQAS
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5KQAS
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 ofSystem.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
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk5AQAS
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk5AQAS
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5AQAS
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk5AQAS
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 LWCrelatedLogEntries
in App Builder. Previously, admins & developers had to manually select a field set first. -
Added new
LoggerParameter__mdt
recordDefaultLogEntryRelatedListFieldSet
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.
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.12.1...v4.12.2
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk55QAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk55QAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk55QAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk55QAC
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 updatingLoggerEmailSender
to include the list of relevant fields for any DML failures that can occur (such as creatingLog__c
andLogEntry__c
records).
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.12.0...v4.12.1
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk4bQAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk4bQAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk4bQAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk4bQAC
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:
Nebula__Log__c.Nebula__LogRetentionDate__c
- initially introduced in the unlocked package inv4.11.5
Nebula__LogEntry__c.Nebula__OriginLocation__c
- initially introduced in the unlocked package inv4.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()
toUrl.getOrgDomainUrl()
-Url.getSalesforceBaseUrl()
was deprecated in v59.0
Enhancements
- Resolved #571 by adding new formula fields
Log__c.TransactionScenarioText__c
andLogEntry__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 toMap<Id, SObject>
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.12...v4.12.0
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mk1wQAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk1wQAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk1wQAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk1wQAC
Core Managed Package - Nebula
namespace
Full Changelog: v4.11.0...v4.12.0
- SF CLI:
sf package install --wait 30 --security-type AdminsOnly --package 04t5Y000001Mk21QAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mk21QAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk21QAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mk21QAC
Bugfix for Lightning Component Entries Not Always Saving
Core Unlocked Package Changes
logger
LWC Changes
- @jamessimone fixed #518 by updating
logger
LWC to defer callingconsole.log()
and to defer saving log entries until afterLoggerSettings__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!
- Previously, logging in some lifecycle events, such as
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.11...v4.11.12
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Mjx5QAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Mjx5QAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mjx5QAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Mjx5QAC
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 methodMessaging.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 methodMessaging.SingleEmailMessage.setTargetObjectId()
. UsingsetTargetObjectId()
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
- Previously, the user ID (
Installation Info
Core Unlocked Package - no namespace
Full Changelog: v4.11.10...v4.11.11
- SF CLI:
sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001Oih7QAC
- SFDX CLI:
sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001Oih7QAC
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Oih7QAC
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001Oih7QAC