feat(disclaimers): Split disclaimers

[kiblik]

Until now, all disclaimers have been the same which is not the best.

Now you can choose between:

• disclaimer_notifications
• disclaimer_reports

There is one more to inform users that they should not include any personal information in notes:

• disclaimer_notes

Plus if there is an internal policy to have a disclaimer in all reports, it is possible to use disclaimer_reports_forced to not allow users to be excluded it.

E.g.:

[dryrunsecurity]

DryRun Security Summary

The pull request enhances the Dojo application's disclaimer handling by introducing more granular system settings, improving security through proper sanitization, and providing administrators with greater flexibility in customizing notification and report disclaimers.

Expand for full summary

Summary:

The code changes in this pull request are focused on improving the handling and customization of disclaimers in various parts of the Dojo application, particularly in the context of notification emails. The key changes include:

1. Separating the disclaimer settings for notifications (system_settings.disclaimer_notifications) from the general system-wide disclaimer (system_settings.disclaimer). This allows for more granular control over the disclaimer content for different types of communications.

2. Updating the templates to use the new system_settings.disclaimer_notifications setting, ensuring that the correct disclaimer is displayed in the notification emails.

3. Properly sanitizing and escaping user-provided content, such as the disclaimer text, to prevent potential security vulnerabilities like Cross-Site Scripting (XSS).

4. Improving the overall flexibility and customization options for the application, allowing administrators to tailor the disclaimer and other notification content as needed.

From an application security perspective, these changes are generally positive, as they demonstrate a focus on security best practices and a desire to provide more control and flexibility over sensitive information displayed to users. However, it's important to ensure that the overall implementation, including the handling of user input and the management of sensitive data, is thoroughly reviewed and tested to maintain the application's security posture.

Files Changed:

• dojo/db_migrations/0219_system_settings_disclaimer_notif.py: This migration introduces new fields for the System_Settings model, including disclaimer_notifications, disclaimer_reports, disclaimer_notes, and disclaimer_reports_forced. These changes provide more granular control over the inclusion of custom disclaimers in various parts of the application.
• dojo/db_migrations/0220_system_settings_disclaimer_notif.py: This migration copies the value of the disclaimer_notifications field to the disclaimer_reports field in the System_Settings model.
• dojo/forms.py: The changes update various forms to include the disclaimer if it is configured in the system settings.
• dojo/reports/views.py: The changes handle the inclusion of the disclaimer in the generated reports, based on the system settings.
• dojo/templates/: The changes in various template files, such as custom_html_report.html, engagement_pdf_report.html, endpoint_pdf_report.html, and others, ensure that the disclaimer is properly rendered and displayed in the application's reports and notifications.
• dojo/models.py: The changes introduce new fields in the System_Settings model to provide more control over the disclaimer settings.
• dojo/templates/dojo/form_fields.html: The changes add a new section to display the disclaimer in the form fields.

Code Analysis

We ran 9 analyzers against 30 files and 1 analyzer had findings. 8 analyzers had no findings.

Analyzer	Findings
Cross-Site Scripting Analyzer	8 findings

Overall Riskiness

🟡 Please give this pull request extra attention during review.

View PR in the DryRun Dashboard.

[Maffooch]

This could be consolidated into the other migration

[kiblik]

I'm not sure I understand this comment