From 68c418731c47cc06fc6c26d2a22b74dae8bd0d00 Mon Sep 17 00:00:00 2001 From: Jonathan Gillespie Date: Tue, 15 Oct 2024 21:40:25 -0400 Subject: [PATCH] Re-ran prettier on README.md --- .github/workflows/build.yml | 14 +++++++------- README.md | 38 ++++++++++++++++++------------------- 2 files changed, 26 insertions(+), 26 deletions(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 599f609ad..b55914382 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -180,7 +180,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage @@ -256,7 +256,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage @@ -324,7 +324,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage @@ -395,7 +395,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage @@ -470,7 +470,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage @@ -538,7 +538,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage @@ -653,7 +653,7 @@ jobs: # Nebula Logger has functionality that queries the AuthSession object when the current user has an active session. # The code should work with or without an active session, so the pipeline runs the tests twice - asynchronously and synchronously. # This is done because, based on how you execute Apex tests, the running user may have an active session (synchrously) or not (asynchronously). - # Utlimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. + # Ultimately, this could/should probably be better mocked during tests, but the AuthSession is read-only in Apex, so it's a bit difficult to work with. # Running the Apex tests sync & async serves as an extra level of integration testing in the meantime to ensure that everything works with or without an active session. - name: 'Run Apex Tests Asynchronously' run: npm run test:apex:nocoverage -- --targetusername nebula-logger-package-demo diff --git a/README.md b/README.md index baeb406a1..c9ce135dd 100644 --- a/README.md +++ b/README.md @@ -829,25 +829,25 @@ If you want to add your own automation to the `Log__c` or `LogEntry__c` objects, ```apex public class ExampleTriggerablePlugin implements LoggerPlugin.Triggerable { - public void execute(LoggerPlugin__mdt configuration, LoggerTriggerableContext input) { - // Example: only run the plugin for Log__c records - if (context.sobjectType != Schema.Log__c.SObjectType) { - return; - } - - List logs = (List) input.triggerNew; - switch on input.triggerOperationType { - when BEFORE_INSERT { - for (Log__c log : logs) { - log.Status__c = 'On Hold'; - } - } - when BEFORE_UPDATE{ - // TODO add before-update logic - } - } - } - } + public void execute(LoggerPlugin__mdt configuration, LoggerTriggerableContext input) { + // Example: only run the plugin for Log__c records + if (context.sobjectType != Schema.Log__c.SObjectType) { + return; + } + + List logs = (List) input.triggerNew; + switch on input.triggerOperationType { + when BEFORE_INSERT { + for (Log__c log : logs) { + log.Status__c = 'On Hold'; + } + } + when BEFORE_UPDATE { + // TODO add before-update logic + } + } + } + } ``` Once you've created your Apex or Flow plugin(s), you will also need to configure the plugin: