wazuh-dashboard-plugins
wazuh-dashboard-plugins copied to clipboard
Add header and footer report customization
Description
This PR is part of White-Labeling Epic https://github.com/wazuh/wazuh-kibana-app/issues/4392. It adds custom text to PDF report header and footer.
Closes https://github.com/wazuh/wazuh-kibana-app/issues/4426 Base: feat/settings-validation
Screenshots
Tests
Manual tests
Scenario: The customization.reports.*
settings should appear in the default configuration file
When the user starts the plugin platform and there is no plugin configuration file
Then the configuration file should be generated and include the customization.reports.*
settings
Scenario: The customization.reports.*
settings should appear in the Settings/Configuration
section
When the user navigates to Settings/Configuration
Then the customization.reports.*
settings should be there
Scenario: Set the customization.reports.header
with a valid value through Settings/Configuration
.
When the user sets the customization.reports.header
with a valid value. Maximum 4 lines.
Then the user can save the configuration successfully.
And the configuration file is updated with the configuration.
Scenario: Set the customization.reports.footer
with a valid value through Settings/Configuration
.
When the user sets the customization.reports.header
with a valid value. Maximum 2 lines.
Then the user can save the configuration successfully.
And the configuration file is updated with the configuration.
Scenario: Set the customization.reports.header
with a invalid value through Settings/Configuration
.
When the user sets the customization.reports.header
with an invalid value. Maximum 4 lines.
Then a validation error is displayed.
Scenario: Set the customization.reports.footer
with a invalid value through Settings/Configuration
.
When the user sets the customization.reports.header
with an invalid value. Maximum 2 lines.
Then a validation error is displayed.
Scenario: Set the customization.reports.header
with a valid value through API request.
When the user does an API request to update the customization.reports.header
setting with a valid value. Maximum 4 lines.
Then the endpoint replies with a successful response.
Scenario: Set the customization.reports.footer
with a valid value through an API request.
When the user does an API request to update the customization.reports.footer
setting with a valid value. Maximum 2 lines.
Then the endpoint replies with a successful response.
Scenario: Set the customization.reports.header
with an invalid value through an API request.
When the user does an API request to update the customization.reports.header
setting with an invalid value. Maximum 4 lines.
Then the endpoint replies with a bad request response.
Scenario: Set the customization.reports.footer
with an invalid value through an API request.
When the user does an API request to update the customization.reports.header
setting with an invalid value. Maximum 2 lines.
Then the endpoint replies with a bad request response.
Scenario: Generate a PDF with a custom header.
Given the customization.reports.header
setting has a custom value.
When generates a PDF module report.
Then the custom text should appear in the header.
Scenario: Generate a PDF with a custom footer.
Given the customization.reports.footer
setting has a custom value.
When generates a PDF module report.
Then the custom text should appear in the footer.
Examples of different logos ratios
Before
After
More width than height:
Equal width and height:
Wazuh Logo for reference
I added some manual tests to the initial comment.
Changes
- Updated the development branch with the last changes of the base branch.
Update
- Update the development branch with the last changes of the base branch.
Update
- Add tests
Update
- Update development branch with the base branch
- Add test related to the validation of the
customization.reports.footer
andcustomization.reports.header
settings in the form inputs
Update
- Add test for the
GET /reports
endpoint
Update
- Update the development branch with the base branch
- Code review: heavy_check_mark
- Test: red_circle
The customization of the logo, header and footer for the PDFs work quite well:
However, I found a few errors:
- The header allows 4 lines of text, however only 3 are actually rendered.
- The inputs limit the number of text lines, but not their length. It's quite easy to break this feature by adding a single, extra long line.
![]()
Texts used:
Powered by Wazuh - This is a custom footer for PDF reports -
Powered by Wazuh ________________________ - This is a custom header for PDF reports - - Provided by the @wazuh/frontend-team -
Yes, the settings only limit the number of lines and not the length of the lines, we could limit if we consider it.
When I developed it, I considered the length of the lines is under the responsibility of the user, so the plugin has no limit that could affect some use cases. Anyways, we could set some value and check the input is valid.
Added max length per line validation.
Code coverage (Jest) | % | values |
---|---|---|
Statements | 8.29% | ( 3037 / 36640 ) |
Branches | 3.83% | ( 1080 / 28200 ) |
Functions | 7.26% | ( 659 / 9080 ) |
Lines | 8.34% | ( 2926 / 35070 ) |
The backport to 4.4-7.16
failed:
The process '/usr/bin/git' failed with exit code 1
To backport manually, run these commands in your terminal:
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-4.4-7.16 4.4-7.16
# Navigate to the new working tree
cd .worktrees/backport-4.4-7.16
# Create a new branch
git switch --create backport-4505-to-4.4-7.16
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 ce29034e17045a808b43390f314b44fbf2c7c8e2
# Push it to GitHub
git push --set-upstream origin backport-4505-to-4.4-7.16
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-4.4-7.16
Then, create a pull request where the base
branch is 4.4-7.16
and the compare
/head
branch is backport-4505-to-4.4-7.16
.