Releases: jongpie/NebulaLogger
Support for logging Map<Id, SObject>, Slack Plugin Improvements
Core Package Changes - v4.9.11
Apex Logging Improvements
- Added new instance method overload
LogEntryEventBuilder.setRecord(Map<Id, SObject> recordIdToRecord)
- For now, I've decided to not add overloads for this in
Logger
directly - I might in a future release, but for now,setRecord()
can be called by chaining the method to one of Logger's methods, likeLogger.info('some message').setRecord(recordIdToRecord)
- For now, I've decided to not add overloads for this in
- Updated
System.debug()
calls inLogger
to start with 'Nebula Logger' instead of just 'Logger' for clarity
Admin Improvements
- Updated formula field
LogEntry__c.LoggingLevelWithImage__c
to use a different emoji for INFO (✅) vs lower levels (⚙️ for DEBUG, FINE, FINER, and FINEST) - Added inline help text to all of the limits-related formula fields on
LogEntry__c
to describe the thresholds used to determine which emojis are shown in the formulas (⛔⚠️ ✅) - Unlocked package-only: Added
AnimationRule
metadata forLog__c.Status__c
to show confetti when the status changes 🥳 🎊
Bugfixes
- Fixed #438 in the "Logger Settings" tab that prevented admins from creating new settings records - all thanks goes to @chazwatkins for reporting & fixing this one!
- Fixed #447 by updating
LogEntryEventHandler
to have an extra null check when processingLogEntryTagRule__mdt
rules - thanks to @ramagrubhubGithub for reporting this - Fixed #453 by simplifying
Logger.getUserSettings()
to always use default field values, and makingLoggerSettingsController
responsible for handling prod-specific settings - thanks to @arbokrad for reporting & chatting through this issue with me- This keeps the behavior of
Logger.getUserSettings()
consistent in all orgs (instead of prod behaving differently from sandboxes/scratch orgs), while still providing the suggested defaults for a prod org via theloggerSettings
LWC/custom tab - Some default field values on
LoggerSettings__c
have also been updated to provide the most detailed settings by default - This bugfix also led to the creation of the new public method
Logger.createSettings()
- this doesn't seem needed in the managed package right now, sopublic
seems sufficient (instead of usingglobal
)
- This keeps the behavior of
Slack Plugin Package Changes - v1.5.2
- Updated
SlackLoggerPlugin
Apex class to leverage a new field set,Log__c.SlackNotificationFields
, to support customization of the fields shown in Slack notifications- This field set can either be directly modified (although changes may be reverted during upgrades), or by creating & specifying another field set in the custom metadata record
LoggerParameter.SlackLogNotificationFieldSet
- The Slack remote site setting has also been renamed from
Slack.remoteSite-meta.xml
toLoggerSlack.remoteSite-meta.xml
to ensure there's consistency in having some variation of the word "Log" in all metadata. Some orgs unintentionally had a previously-existing remote site setting (also named just "Slack") unintentionally overwritten - this name change should help avoid overwriting existing remote site settings for Slack.
- This field set can either be directly modified (although changes may be reverted during upgrades), or by creating & specifying another field set in the custom metadata record
Installation Info
Moving forward, new release notes will now include this section to provide the sfdx
installation commands & installation links for any new package versions. Thanks to @MeStrak for pointing out that the CLI commands weren't included anywhere in the docs - including these details in the release notes will make is much easier for everyone to easily install a specific version, using whichever installation method you prefer.
Please note that the included sfdx
commands use the latest syntax and parameters - these versions of the commands may not work with older versions of sfdx
, as newer versions of sfdx
use a simpler syntax, and some command parameters have been renamed.
Core Unlocked Package - no namespace
- SFDX CLI:
sfdx package install --apex-compile package --wait 20 --security-type AdminsOnly --package 04t5Y0000015nDxQAI
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015nDxQAI
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015nDxQAI
Slack Unlocked Package Plugin - no namespace
- SFDX CLI:
sfdx package install --apex-compile package --wait 20 --security-type AdminsOnly --package 04t5Y0000015nDJQAY
- Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015nDJQAY
- Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015nDJQAY
Added Search Result Fields for All Custom Objects
Core Unlocked Package Changes
Admin Improvements
-
Closed #443 (reported by @solo-1234) by updating all custom objects to have relevant fields on the search results layouts
Log__c
search results now display the fieldsName
,LoggedByUsernameLink__c
,StartTime__c
,OWNER
,Priority__c
,Status__c
,TransactionId__c
,TotalLogEntries__c
,TotalERRORLogEntries__c
,TotalWARNLogEntries__c
-
LogEntry__c
search results now display the fieldsName
,LoggedByUsernameLink__c
,Timestamp__c
,Log__c
,LoggingLevelWithImage__c
,Message__c
,OriginType__c
,OriginLocation__c
-
LogEntryTag__c
search results now display the fieldsName
,LoggedByUsernameLink__c
,LogLink__c
,LogEntryTimestamp__c
,LogEntry__c
,LogEntryOrigin__c
,Tag__c
-
LoggerTag__c
search results now display the fieldsName
,TotalLogEntries__c
,UniqueId__c
,OWNER
,CREATED_DATE
,LAST_UPDATE
-
LoggerScenario__c
search results now display the fieldsName
,UniqueId__c
,OWNER
,CREATED_DATE
,LAST_UPDATE
-
Also added descriptions to all of the custom objects
Test Improvements
- @mohan-chinnappan-n found and fixed (in PR #432) an issue with a test in
LoggerSettingsController_Tests
- one of the tests would fail if the current user running the tests did not have a value in the fieldUser.FirstName
New Configurable Storage Locations For Scenario & Tag Data
Core Unlocked Package Changes
Fixed #388 (reported by @rmccu) by providing controls for how scenario & tag data is stored in Nebula Logger's data model. As the data model has grown over the last year or so, using multiple custom objects has made it easier for admins & developers to manage scenario & tag data - however, the data model does not scale well in orgs with large data volumes (LDV) of millions of records because of data skew that can happen for scenarios & tags that are heavily used.
- 🟥 Red box in the below data model: A single
LoggerScenario__c
record can end up with millions of relatedLog__c
andLogEntry__c
records - 🟩 Green box in the below data model: A single
LoggerTag__c
record can end up with millions of relatedLogEntryTag__c
junction records (that linkLoggerTag__c
toLogEntry__c
)
This type of data skew can lead to row-lock errors, increased runtimes for deleting data via LogBatchPurger
, and other types of headaches.
To help avoid these kinds of issues, orgs with large data volumes can now choose if scenario & tag data are normalized (stored in custom objects) or denormalized (stored in text fields directly on Log__c
and LogEntry__c
). This can be controlled with 2 new LoggerParameter__mdt
records (shown in the screenshot below):
- New
LoggerParameter__mdt
recordNormalizeScenarioData
- When set to
true
(default), scenario data is stored in the custom objectLoggerScenario__c
- When set to
false
, scenario data is stored in the text fieldsLog__c.TransactionScenarioName__c
andLogEntry__c.EntryScenarioName__c
- To simplify things like list views & related lists, the 2 new formula fields
Log__c.TransactionScenarioLink__c
andLogEntry__c.EntryScenarioLink__c
will handle displaying either the value of the corresponding text field or the name of the relatedLoggerScenario__c
record
- When set to
- New
LoggerParameter__mdt
recordNormalizeTagData
- When set to
true
(default), tag data is stored in the custom objectsLoggerTag__c
andLogEntryTag__c
(orTopic
andTopicAssignment
, if theLoggerParameter__mdt
recordUseTopicsForTags
is set totrue
) - When set to
false
, tag data is stored in the long text area fieldLogEntry__c.Tags__c
, and the new fieldLogEntry__c.HasInlineTags__c
is set to true (since long text area fields can't be filtered in SOQL/list views, this field helps with filtering)
- When set to
Full Changelog: v4.9.8...v4.9.9
Testing Fixes & Improvements
Pipeline Improvements
- Fixed an issue that was recently introduced into the pipeline (
build.yml
) that was preventing tests in theextra-tests
folder from being deployed/executed, which caused the reported code coverage to drop several percentage points (95% to 91%)- This was caused by recently switching to use
sfdx force:source:push
instead ofsfdx force:source:deploy
- for some reason, theextra-tests
folder was not being pushed to the scratch orgs in the pipeline, so I've reverted back to usingsfdx force:source:deploy
- This was caused by recently switching to use
- Updated
package-lock.json
to fix a dependabot security alert in GitHub - Renamed npm scripts 'lint' to 'scan'
Core Unlocked Package Changes
After resolving the above pipeline issue, I've updated several Apex test classes to cover edge scenarios that the existing tests didn't cover - this also led to fixing a few issues:
- Fixed an issue in
LoggerPlugin
where a runtime error would occur if the specified Apex class for a plugin did not implement the corresponding interface (LoggerPlugin.Batchable
orLoggerPlugin.Triggerable
) - now,LoggerPlugin
gracefully skips any misconfigured plugins/classes. - Updated
LogBatchPurgeController
class to use strongly-typed SObject tokens, instead of hardcoded Strings - Removed some
try-catch
blocks in a few classes where an exception is not expected to occur - Removed an old/deprecated private method,
LogEntryEventBuilder.setTransactionDetails()
- Fixed an incorrect Boolean check in
LoggerEngineDataSelector
that preventedNetwork
data from being properly queried - Fixed #424 - the field
LogEntryEvent__e.RequestId__c
had been incorrectly flagged as a required field, and as reported by @chazwatkins, the value ofSystem.Request.getCurrent().getRequestId()
is null for theautoproc
user (and possibly other scenarios).
Full Changelog: v4.9.7...v4.9.8
Added new field Log__c.HasComments__c
Core Unlocked Package Changes
- Added new Boolean field
Log__c.HasComments__c
that's automatically set in theLogHandler
class, based on if the fieldLog__c.Comments__c
is populated. Since the fieldLog__c.Comments__c
is a long textarea field, it can't be filter in SOQL, list views, etc. which makes it very difficult to find log records where someone has entered comments. The new Boolean field is setBEFORE_INSERT
andBEFORE_UPDATE
- existing records (in orgs that are upgrading) will need to be re-saved in order to have the new field correctly populated.
Updated Logger.getUserSettings() to set defaults based on the environment type
Core Unlocked Package Changes
- Updated
LoggerSettings__c
fieldsLoggingLevel__c
,IsApexSystemDebugLoggingEnabled__c
, andIsJavaScriptConsoleLoggingEnabled__c
to make the default values be the recommended values for production orgs - Closed #364 by updating
Logger.getUserSettings()
to set some field values based on if the current org is a sandbox. This also applies when using the included 'Logger Settings' tab (which displays the LWCloggerSettings
).- In production, the default field values are now:
LoggingLevel__c
now defaults to 'INFO'IsApexSystemDebugLoggingEnabled__c
andIsJavaScriptConsoleLoggingEnabled__c
default tofalse
- In sandboxes & scratch orgs, the default field values are now:
LoggingLevel__c
now defaults to 'FINEST'IsApexSystemDebugLoggingEnabled__c
andIsJavaScriptConsoleLoggingEnabled__c
default totrue
- In production, the default field values are now:
- Updated
LoggerEngineDataSelector
class to still leverage data cached in Platform Cache (if available), even if querying is disabled for a particular method - Added the
System
namespace to all references to theFeatureManagement
class - this helps avoid naming collisions in orgs using the unlocked package that have a custom class with the same name - Removed some lingering references to
Logger
inLogEntryBuilder
&LogEntryBuilder_Tests
, which finishes up some ongoing tech debt cleanup to makeLogEntryEventBuilder
independent/unaware ofLogger
Pipeline Improvements
- Made test execution faster in the pipeline by updating
build.yml
to skip unnecessary code coverage calculations for all test runs except for the final synchronous run in the Experience Cloud scratch org (when code coverage data is uploaded to Codecov.io)
Configurable Platform Cache Partition Name
Core Unlocked Package Changes
-
Added new CMDT record
LoggerParameter.PlatformCachePartitionName
to control which platform cache partition is used for caching -
Updated
LoggerCache
to gracefully handle a nonexistent Platform Cache partition - it internally falls back to using the transaction cache, which doesn't rely on Platform Cache. This is helpful in ensuring that Nebula Logger still works, even if theLoggerParameter.PlatformCachePartitionName
record has been misconfigured and/or the corresponding platform cache partition cannot be found.
Pipeline Improvements
- Updated
codecov.yml
to ignore sample metadata used in the pipeline for creating an Experience Cloud site - this was previously skewing the code coverage results for the repo, since these classes are only used by the pipeline for testing purposes, the code coverage of these classes is irrelevant
Migrated to new System.Assert class, added System namespace to several references
Core Unlocked Package Changes
This release doesn't have any functional changes (hopefully 😅) - it just contains some tech-debt & cleanup in several classes, and it was cleaner to do this as standalone release.
- Migrated all asserts to use the new class
System.Assert
- Added the
System
namespace to all of the below references - this helps avoid naming collisions in orgs that have custom classes with 1 (or more) of these names- Classes
Exception
,AuraHandledException
,CalloutException
, andIllegalArgumentException
Http
,HttpRequest
, andHttpResponse
SObjectAccessDecision
UserInfo
- Enums
AccessType
LoggingLevel
- Classes
New Indicator Icons
Core Unlocked Package Changes
-
Updated formula fields on
LogEntry__c
to replace old flag icons with emojis that are more visually distinct from one another -
Updated format of
LogEntry__c
limits formula fields to display percentage first (after new indicators) with limit used & max fields displayed in parenthesis
Both of these changes are shown in this screenshot
- The "SOQL Queries" formula field shows an error (⛔) since 90-100% of the limit has been used (94 out of 100 queries)
- The "DML Statements" formula field shows a warning (
⚠️ ) since 80-90% of the limit has been used (127 out of 150 DML statements) - The remaining formula fields show a checkbox (✅) since less than 80% of the limits have been used (with corresponding values for Used / Max in parenthesis)
Enhancements for Log Entry Event Stream Tab/LWC
Core Unlocked Package Changes
Another stellar community contribution from @mar-ben - this release provides several enhancements to the logEntryEventStream
LWC that's used for monitoring published LogEntryEvent__e
platform event records.
- Added split-view toggling - you can now close & open the filter menu (shown on the left side of the LWC)
- Added tabular view - using the new "Display As" button (shown in the top-right of the LWC), you can switch between the console view & the new tabular view. The list of fields displayed can be configured in the
LoggerParameter__mdt
object by updating the recordLoggerParameter.LogEntryEventStreamDisplayFields
- Added full-screen mode - using the new "Expand"/"Contract" button (shown in the top-right of the LWC), you can also switch to a larger view so you can more easily see the
LogEntryEvent__e
data.
Thanks again to @mar-ben for the fantastic enhancements!