Store HttpResponse header values

[jongpie]

New Feature: Store HttpResponse Header Values

• Resolved Log headers from HttpResponse (and possibly HttpRequest) objects #561 (reported by @TrangOul) by adding new fields LogEntryEvent__e.HttpResponseHeaders__c and LogEntry__c.HttpResponseHeaders__c that store the full key-value pair for each header set on the logged instance of System.HttpResponse. These fields are now automatically set when using the instance method LogEntryEventBuilder.setHttpResponseDetails(System.HttpResponse).

  • Based on the great suggestion from @TrangOul, each header key-value pair is stored in the format Header: value to match the (HTTP standard). A \n line break is used as a delimiter between each header when there are multiple headers.
  • For orgs that do not want to store the header values (either due to security concerns with storing this information, or other concerns), you can disable this functionality org-wide by updating the new LoggerParameter__mdt record StoreHttpResponseHeaderValues to false. By default, this feature is enabled/set to true
  • The existing fields LogEntryEvent__e.HttpResponseHeaderKeys__c and LogEntry__c.HttpResponseHeaderKeys__c will continue to be populated. These fields store only the header keys, not the header values, and some orgs have existing tests & logic that rely on checking the logged keys. These fields are always populated for instances of System.HttpResponse, regardless of the configuration of the new LoggerParameter__mdt record StoreHttpResponseHeaderValues.

• Updated permission sets LoggerAdmin and LoggerLogViewer to have read access to the new field LogEntry__c.HttpResponseHeaders__c.

  • The permission set LoggerEndUser intentionally does not have access to this field (or any other fields related to HttpResponse or HttpRequest).

• Added new field LogEntry__c.HttpResponseHeaders__c to the FlexiPage LogEntryRecordPage. This field is shown in addition to the existing field LogEntry__c.HttpResponseHeaderKeys__c, shown in the (massive 😅) screenshot below

  

Updated Internal Coding Conventions for Apex if Statements

• Updated ~300 if statements throughout the codebase to simplify checking Booleans from if(condition == true) to just if(condition). A few existing Booleans were also updated to have a default value to avoid issues with null values.
  • This (hopefully) shouldn't impact any functionality in Nebula Logger - the goal of this change is purely to update the coding style used within the codebase to be a bit more concise, based on some feedback received over the last year or so, including a discussion last year with @rmccu in explicit check for true? #383 and PR comment from @TrangOul.

[codecov]

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Files	Coverage Δ
...er/core/main/configuration/classes/LoggerCache.cls	98.83% <100.00%> (ø)
...ore/main/configuration/classes/LoggerParameter.cls	100.00% <100.00%> (ø)
...r/core/main/configuration/classes/LoggerPlugin.cls	96.92% <100.00%> (ø)
...log-management/classes/LogBatchPurgeController.cls	100.00% <100.00%> (ø)
.../log-management/classes/LogBatchPurgeScheduler.cls	100.00% <100.00%> (ø)
...re/main/log-management/classes/LogEntryHandler.cls	92.85% <100.00%> (ø)
...er/core/main/log-management/classes/LogHandler.cls	99.31% <100.00%> (ø)
...g-management/classes/LogManagementDataSelector.cls	100.00% <100.00%> (ø)
...-management/classes/LoggerHomeHeaderController.cls	100.00% <100.00%> (ø)
...n/log-management/classes/LoggerSObjectMetadata.cls	100.00% <100.00%> (ø)
... and 19 more

📢 Thoughts on this report? Let us know!.