Phishing - deduplication of HTML fields to improve performance #26517
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ere Email.Text would take precedence over Email.HTML if we keep the old fields)
… section to be under the email delete button section
This PR was automatically updated by a GitHub Action
To stop automatic version bumps, add the |
Packs/Campaign/Playbooks/Detect_&_Manage_Phishing_Campaigns.yml
Outdated
Show resolved
Hide resolved
Packs/Campaign/Playbooks/Detect_&_Manage_Phishing_Campaigns.yml
Outdated
Show resolved
Hide resolved
Packs/Campaign/Playbooks/Detect_&_Manage_Phishing_Campaigns.yml
Outdated
Show resolved
Hide resolved
|
@ArikDay @AdiPeret @tomer-pan Doc review completed. |
Co-authored-by: ShirleyDenkberg <62508050+ShirleyDenkberg@users.noreply.github.com>
Co-authored-by: ShirleyDenkberg <62508050+ShirleyDenkberg@users.noreply.github.com>
Co-authored-by: ShirleyDenkberg <62508050+ShirleyDenkberg@users.noreply.github.com>
Co-authored-by: ShirleyDenkberg <62508050+ShirleyDenkberg@users.noreply.github.com>
Co-authored-by: ShirleyDenkberg <62508050+ShirleyDenkberg@users.noreply.github.com>
…nt into phishing-dedup-html-fields
This PR was automatically updated by a GitHub Action
To stop automatic version bumps, add the |
|
@ShirleyDenkberg can you please review the RN again? I modified the RN to emphasize that while we do recommend to change the value of the input - it can break backward compatibility for the users if they're using custom content. |
tomer-pan
reviewed
May 23, 2023
…nt into phishing-dedup-html-fields
|
|
||
| ##### Detect & Manage Phishing Campaigns | ||
|
|
||
| Changed the playbook to use the *Email HTML* field instead of the *Email Body HTML* by default. We recommend that users change to the value locally as well. This change should not affect the functionality of the playbook. |
There was a problem hiding this comment.
Suggested change
| Changed the playbook to use the *Email HTML* field instead of the *Email Body HTML* by default. We recommend that users change to the value locally as well. This change should not affect the functionality of the playbook. | |
| Changed the playbook to use the *Email HTML* field instead of the *Email Body HTML* by default. We recommend that users change the value locally as well. This change should not affect the functionality of the playbook. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status
In Progress
Related Issues
fixes: https://jira-hq.paloaltonetworks.local/browse/CRTX-81822
Description
Email Body HTMLandRendered HTMLfields.The flag should be set to False if the user experiences errors due to incident object size. Setting the flag to False will break backward compatibility if the user depends on the
Email Body HTMLorRendered HTMLfields in their playbooks.The field
Email HTMLshould be used instead, and theEmail Bodyfield should be used for plan-text email bodies.Minimum version of Cortex XSOAR
6.5.0
Does it break backward compatibility?
No / Yes (depending on what we will decide about the flag's default value.)