-
-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for logging Map<Id, SObject> #222
Labels
Layer: Logger Engine
Items related to the core logging engine
Logging Source: Apex
Items related to using Logger within Apex
Type: Enhancement
New feature or request
Milestone
Comments
jongpie
added
Type: Enhancement
New feature or request
Logging Source: Apex
Items related to using Logger within Apex
Layer: Logger Engine
Items related to the core logging engine
labels
Oct 8, 2021
jongpie
added a commit
that referenced
this issue
Apr 12, 2022
…__c and RecordCollectionSize__c - I had planned to add these as part of #222, but decided to add them now so I could duplicate the fields to the LogEntryArchive__b big object as well. This also helped to identify (and fix) some issues with missing asserts in LogEntryEventHandler_Tests.
jongpie
added a commit
that referenced
this issue
May 2, 2022
…on Rules plugin (#298) - Replaced `LoggerSObjectHandlerPlugin` abstract class with new class `LoggerPlugin` that contains 2 interfaces + helper methods, switched to using multiple fields on `LoggerPlugin__mdt` to indicate Apex classes & Flows to run for a plugin, removed SObject-specific fields on `LoggerPlugin__mdt`, added new fields `Log__c.LogPurgeAction__c` and `LoggerSettings__c.DefaultLogPurgeAction__c` - Added support for plugins within LogBatchPurger + added archiving in BigObject plugin (#288) - Added SObject-specific 'execution order' fields on `LoggerPlugin__mdt` - Added picklist values for API versions in calendar year 2022 - Reintroduced the ability to disable trigger handler classes by adding new `LoggerParameter__mdt` records to control via configuration - Renamed CMDT records that control each trigger handler - Added new abstract methods in LoggerSObjectHandler for retrieving each handler's related records in `LoggerParameter__mdt` & `LoggerPlugin__mdt` - Added the ability to configure the list of save methods shown in `loggerSettings` LWC via `LoggerParameter__mdt`, using the prefix 'CustomSaveMethod' - Standardized test-visible method naming conventions to start with `setMock` & updated approaches to use a Map instead of List for CMDT records - Fixed issues in LoggerSObjectHandler for invalid Apex & Flow plugins, started new test class LoggerSObjectHandler_Tests - Added `Log__c` list view to show logs that will be purged in the next 10 days, fixed LogEntryArchiveBuilder using the wrong value for LoggedById**c, updated index on LogEntryArchive**b again (still a WIP), retrieved & formatted metadata for LogEntryArchive\*\*b, updated Admin.profile - Closed #226 by adding new "Log Retentions Rule" plugin, based on my other project, ApexValidationRules - @jamessimone closed #117, and I closed #228 by adding new "Big Object Archiving" plugin - Lowercased the plugin directories - Added plugins folder to the script for generating apex doc files, generated updated docs for Apex - Bumped package version number for the managed package - Added 5 minute wait between unlocked package version creation & package installation, added deprecated `LoggerPlugin__mdt` validation rule & field back into the managed-package folder, cleaned up some docs markdown files - Added tests in LoggerSettingsController_Tests & LogHandler_Tests for new custom setting LoggerSettings**c.DefaultLogPurgeAction**c - Added 'deprecated' to the label of several deprecated fields on `LoggerPlugin__mdt` & removed the related handler methods - More improvements for CMDT records used in the classes LoggerParameter & LoggerPlugin - Added LoggerParameter.matchOnPrefix() to return CMDT records with a specified prefix in the DeveloperName field - Added inner Comparable class in LoggerPlugin to handle custom sorting, since there are some limitations with SOQL queries for CMDT - Classes like LogBatchPurger, LoggerSObjectHandler, and LoggerSettingsController no longer need to track their own mock CMDT records, the LoggerPlugin & LoggerParameter classes now fully handle mocks for their corresponding CMDT objects - LoggerParameter & LoggerPlugin now require mock CMDT records to have DeveloperName populated - they'll throw errors if the field is null - Also added System namespace to some calls for Test.isRunningTest() to handle crazy orgs that have a custom Test class deployed - Added the ability to disable all triggers during tests via new @testvisible method LoggerSObjectHandler.shouldExecute(Boolean) - Moved LoggerTestUtils to the configuration folder, added public methods for mocking all CMDT records - Consolidated plugin-framework folders back into the configuration folders - Moved demo experience cloud metadata under config, instead of under nebula-logger, updated build.yml to deploy instead of push metadata - Updated test classes to use new overloads for LoggerTestUtils.setMock() - Added new class LoggerDataStore to centralize all database, event bus & queueable operations - Closed #193 by adding classes `LoggerMockDataCreator` for generic mock & data creation (part of configuration layer), `LoggerTestConfigurator` forNebula Logger-specific mocking & setup (part of the log-management layer), and `LoggerMockDataStore` for mocking database & event bus operations throughout the codebase - Started work on #292 by adding businessStatus, complianceGroup & securityClassification nodes to several custom fields (still a WIP) - Rewrote tests in `LogEntryEventBuilder_Tests` to use new methods in `LoggerMockDataCreator` for creating mock instances of database result classes - Scope creep: added fallback fields for setting `RecordName__c` in LogEntryHandler on objects that don't have a display name field, also added some caching - Moved permissionSets and customPermissions folders from configuration to log-management - This should make the configuration folder fully standalone (i.e., it could be deployed by itself) - The perm sets were already referencing all of the objects within log-management, so it seems like it's better to keep the perm sets organized with - Changed labels to just "Entry #" on both `LogEntryEvent__e` and `LogEntryArchive__b` - Fixed an issue in `LogEntryEventBuilder` where some stack trace lines would be duplicated - Scope creeped a bit by adding new fields `DatabaseResultCollectionSize__c` and `RecordCollectionSize__c` - I had planned to add these as part of #222, but decided to add them now so I could duplicate the fields to the `LogEntryArchive__b` big object as well. This also helped to identify (and fix) some issues with missing asserts in LogEntryEventHandler_Tests. - Replaced settings field `IsPlatformEventStorageEnabled__c` with new field `DefaultPlatformEventStorageLocation__**__c`, providing a way for plugins (big object plugin in particular) to provide additional storage location. The big object plugin provides a custom option BIG_OBJECT, in addition to the default value CUSTOM_OBJECTS that will now be used out of the box - Added stack trace fields to the Slack message created via SlackLoggerPlugin - Updated most test classes to use `@IsTest(isParallel=true)`. A few tests (especially integration tests) that do DML on User can't use parallel testing, but most test classes are now using it - Partially implemented #240 by adding HTTP Request & HTTP Response fields to `LogEntryEvent__e`, `LogEntry__c` and `LogEntryArchive__b`. More scope creep yet again, but this will save some headaches long term - since Big Objects can't (easily) have new fields added, I wanted to go ahead and get these new fields added to the data model before the first release of the Big Object plugin. I'll probably add some logging overloads in Logger for these items in a future release, but for now, only LogEntryEventBuilder has new methods for HttpRequest & HttpResponse - Updated some internal debug messages in various places to use Logger's logging methods, instead of `System.debug()` - Deprecated the fields `LogEntryDataMaskRule__mdt.ApplyToMessage__c` and `LogEntryDataMaskRule__mdt.ApplyToRecordJson__c` - Fixed test failures that occur when email deliverability is disabled in an org Co-authored-by: James Simone <[email protected]>
jongpie
modified the milestones:
Version 4.8.0: Summer '22 Release,
Version 4.9.0: Winter '23 Release
Jul 19, 2022
jongpie
changed the title
Add support for logging Set<SObject> and Map<Id, SObject>
Add support for logging Map<Id, SObject>
Aug 29, 2022
Due to some Apex limitations, I'm not going to implement support for logging |
jongpie
modified the milestones:
Version 4.9.0: Winter '23 Release,
Version v4.10.0 - Spring '23 Release
Sep 26, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Layer: Logger Engine
Items related to the core logging engine
Logging Source: Apex
Items related to using Logger within Apex
Type: Enhancement
New feature or request
Discussed in #221
Originally posted by mmakara2021 October 7, 2021
Hello curently I was not able to figure out how to log Set and Map in apex code.
Yes there some king of workaround?
thanks
The text was updated successfully, but these errors were encountered: