Skip to content

Releases: jongpie/NebulaLogger

Support for logging Map<Id, SObject>, Slack Plugin Improvements

15 Mar 03:21
46ddff1
Compare
Choose a tag to compare

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, like Logger.info('some message').setRecord(recordIdToRecord)
  • Updated System.debug() calls in Logger 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 for Log__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 processing LogEntryTagRule__mdt rules - thanks to @ramagrubhubGithub for reporting this
  • Fixed #453 by simplifying Logger.getUserSettings() to always use default field values, and making LoggerSettingsController 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 the loggerSettings 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, so public seems sufficient (instead of using global)

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 to LoggerSlack.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.

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

Slack Unlocked Package Plugin - no namespace

Added Search Result Fields for All Custom Objects

23 Jan 20:11
4ca9535
Compare
Choose a tag to compare

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 fields Name, LoggedByUsernameLink__c, StartTime__c, OWNER, Priority__c, Status__c, TransactionId__c, TotalLogEntries__c, TotalERRORLogEntries__c, TotalWARNLogEntries__c

    image

    • LogEntry__c search results now display the fields Name, LoggedByUsernameLink__c, Timestamp__c, Log__c, LoggingLevelWithImage__c, Message__c, OriginType__c, OriginLocation__c

      image

    • LogEntryTag__c search results now display the fields Name, LoggedByUsernameLink__c, LogLink__c, LogEntryTimestamp__c, LogEntry__c, LogEntryOrigin__c, Tag__c

      image

    • LoggerTag__c search results now display the fields Name, TotalLogEntries__c, UniqueId__c, OWNER, CREATED_DATE, LAST_UPDATE

      image

    • LoggerScenario__c search results now display the fields Name, UniqueId__c, OWNER, CREATED_DATE, LAST_UPDATE

      image

  • Also added descriptions to all of the custom objects

    image

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 field User.FirstName

New Configurable Storage Locations For Scenario & Tag Data

08 Dec 21:22
4814f4e
Compare
Choose a tag to compare

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 related Log__c and LogEntry__c records
  • 🟩 Green box in the below data model: A single LoggerTag__c record can end up with millions of related LogEntryTag__c junction records (that link LoggerTag__c to LogEntry__c)

This type of data skew can lead to row-lock errors, increased runtimes for deleting data via LogBatchPurger, and other types of headaches.

image

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):

  1. New LoggerParameter__mdt record NormalizeScenarioData
    • When set to true (default), scenario data is stored in the custom object LoggerScenario__c
    • When set to false, scenario data is stored in the text fields Log__c.TransactionScenarioName__c and LogEntry__c.EntryScenarioName__c
    • To simplify things like list views & related lists, the 2 new formula fields Log__c.TransactionScenarioLink__c and LogEntry__c.EntryScenarioLink__c will handle displaying either the value of the corresponding text field or the name of the related LoggerScenario__c record
  2. New LoggerParameter__mdt record NormalizeTagData
    • When set to true (default), tag data is stored in the custom objects LoggerTag__c and LogEntryTag__c (or Topic and TopicAssignment, if the LoggerParameter__mdt record UseTopicsForTags is set to true)
    • When set to false, tag data is stored in the long text area field LogEntry__c.Tags__c, and the new field LogEntry__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)

image

Full Changelog: v4.9.8...v4.9.9

Testing Fixes & Improvements

07 Dec 20:34
3317ac8
Compare
Choose a tag to compare

Pipeline Improvements

  • Fixed an issue that was recently introduced into the pipeline (build.yml) that was preventing tests in the extra-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 of sfdx force:source:deploy - for some reason, the extra-tests folder was not being pushed to the scratch orgs in the pipeline, so I've reverted back to using sfdx force:source:deploy
  • 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 or LoggerPlugin.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 prevented Network 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 of System.Request.getCurrent().getRequestId() is null for the autoproc user (and possibly other scenarios).

Full Changelog: v4.9.7...v4.9.8

Added new field Log__c.HasComments__c

30 Nov 16:16
f735959
Compare
Choose a tag to compare

Core Unlocked Package Changes

  • Added new Boolean field Log__c.HasComments__c that's automatically set in the LogHandler class, based on if the field Log__c.Comments__c is populated. Since the field Log__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 set BEFORE_INSERT and BEFORE_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

30 Nov 14:29
d91e665
Compare
Choose a tag to compare

Core Unlocked Package Changes

  • Updated LoggerSettings__c fields LoggingLevel__c, IsApexSystemDebugLoggingEnabled__c, and IsJavaScriptConsoleLoggingEnabled__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 LWC loggerSettings).
    • In production, the default field values are now:
      • LoggingLevel__c now defaults to 'INFO'
      • IsApexSystemDebugLoggingEnabled__c and IsJavaScriptConsoleLoggingEnabled__c default to false
    • In sandboxes & scratch orgs, the default field values are now:
      • LoggingLevel__c now defaults to 'FINEST'
      • IsApexSystemDebugLoggingEnabled__c and IsJavaScriptConsoleLoggingEnabled__c default to true
  • 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 the FeatureManagement 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 in LogEntryBuilder & LogEntryBuilder_Tests, which finishes up some ongoing tech debt cleanup to make LogEntryEventBuilder independent/unaware of Logger

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

29 Nov 21:31
ebe5796
Compare
Choose a tag to compare

Core Unlocked Package Changes

  • Added new CMDT record LoggerParameter.PlatformCachePartitionName to control which platform cache partition is used for caching

    image

  • 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 the LoggerParameter.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

23 Nov 18:23
e6448bd
Compare
Choose a tag to compare

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, and IllegalArgumentException
      • Http, HttpRequest, and HttpResponse
      • SObjectAccessDecision
      • UserInfo
    • Enums
      • AccessType
      • LoggingLevel

New Indicator Icons

23 Nov 16:03
125b08c
Compare
Choose a tag to compare

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

    image

  • Updated format of LogEntry__climits 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)

image

Enhancements for Log Entry Event Stream Tab/LWC

22 Nov 23:27
956205d
Compare
Choose a tag to compare

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.

  1. Added split-view toggling - you can now close & open the filter menu (shown on the left side of the LWC)

image

  1. 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 record LoggerParameter.LogEntryEventStreamDisplayFields

image

  1. 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.

image

Thanks again to @mar-ben for the fantastic enhancements!