Make email footer line configurable #8326
Conversation
📝 WalkthroughWalkthroughThe pull request introduces a configurable footer for email templates across the application. A new configuration parameter Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
@hotzenklotz I noticed that there is an unused email template file called There I see a block where I would guess the lower branch may have been supposed to be that other email. If you agree, I can connect them in this PR. Otherwise, I’d delete the file. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (8)
app/views/mail/jobSuccessfulUploadConvert.scala.html (1)
36-43: Consider enhancing image accessibility.While the alt text is descriptive, consider adding
role="presentation"to these marketing images since they are decorative and supplementary to the main content. This helps screen readers understand that these images are not essential to the core message.<img src="https://static.webknossos.org/mails/email-alignment-preview.600.jpg" - alt="A preview of the alignment services for a WEBKNOSSOS dataset" + alt="A preview of the alignment services for a WEBKNOSSOS dataset" + role="presentation" style="width: 300px; height: 150px;" /> <img src="https://static.webknossos.org/mails/email-segmentation-preview.600.jpg" - alt="A preview of a full, automated segmentation of a WEBKNOSSOS dataset" + alt="A preview of a full, automated segmentation of a WEBKNOSSOS dataset" + role="presentation" style="width: 300px; height: 150px;" />conf/application.conf (1)
244-244: Consider making footer styling configurable.The footer HTML has hardcoded styling (color: #888). Consider extracting the styles to make them configurable or consistent with your email template's theme.
app/mail/DefaultMails.scala (1)
28-28: Consider using a base email template class.The pattern of passing
additionalFooterto every email template is repetitive. Consider creating a base email template class that automatically includes the footer, reducing duplication and making future email template changes easier to maintain.Also applies to: 36-37, 45-45, 53-53, 61-61, 69-69, 77-77, 90-91, 100-100, 108-108, 116-116, 124-124, 132-132, 143-144, 157-159, 167-167, 179-179, 187-187, 195-195, 206-206
app/views/mail/upgradePricingPlanUsers.scala.html (1)
8-8: Consider formatting for the numeric value.The
requestedUsersvalue might benefit from proper formatting (e.g., thousands separators) for better readability in the email.app/views/mail/invite.scala.html (1)
1-1: Remove extra space before closing parenthesisThere's an unnecessary space before the closing parenthesis in the parameter list.
-@(senderName: String, organizationName: String, inviteTokenValue: String, uri: String, autoVerify: Boolean, additionalFooter: String ) +@(senderName: String, organizationName: String, inviteTokenValue: String, uri: String, autoVerify: Boolean, additionalFooter: String)app/views/mail/newUser.scala.html (2)
1-1: Remove extra space before closing parenthesisThere's an unnecessary space before the closing parenthesis in the parameter list.
-@(name: String, enableAutoVerify: Boolean, additionalFooter: String ) +@(name: String, enableAutoVerify: Boolean, additionalFooter: String)
1-1: Consider implementing HTML sanitization middlewareGiven that HTML content is being injected via configuration across multiple email templates, consider implementing:
- A centralized HTML sanitization middleware
- Unit tests with malicious HTML payloads
- Documentation for safe HTML content guidelines
Would you like me to help create:
- A sanitization middleware implementation
- Unit tests for HTML injection scenarios
- Documentation for HTML content guidelines
app/views/mail/emailBaseTemplate.scala.html (1)
48-50: Consider adding validation for empty footer content.The current implementation might render an empty paragraph when
additionalFooteris empty. Consider adding a condition to only render the paragraph when content is present.- <p style="color: #888; font-size: 0.6rem;"> - @Html(additionalFooter) - </p> + @if(additionalFooter.nonEmpty) { + <p style="color: #888; font-size: 0.6rem;"> + @Html(additionalFooter) + </p> + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (25)
app/mail/DefaultMails.scala(8 hunks)app/utils/WkConf.scala(1 hunks)app/views/mail/emailBaseTemplate.scala.html(2 hunks)app/views/mail/extendPricingPlan.scala.html(1 hunks)app/views/mail/help.scala.html(1 hunks)app/views/mail/invite.scala.html(1 hunks)app/views/mail/jobFailedGeneric.scala.html(2 hunks)app/views/mail/jobFailedUploadConvert.scala.html(2 hunks)app/views/mail/jobSuccessfulGeneric.scala.html(2 hunks)app/views/mail/jobSuccessfulSegmentation.scala.html(2 hunks)app/views/mail/jobSuccessfulUploadConvert.scala.html(2 hunks)app/views/mail/newUser.scala.html(1 hunks)app/views/mail/notifyAdminNewOrganization.scala.html(1 hunks)app/views/mail/notifyAdminNewUser.scala.html(1 hunks)app/views/mail/notifyAdminTimeLimit.scala.html(2 hunks)app/views/mail/passwordChanged.scala.html(1 hunks)app/views/mail/resetPassword.scala.html(1 hunks)app/views/mail/upgradePricingPlanRequest.scala.html(1 hunks)app/views/mail/upgradePricingPlanStorage.scala.html(1 hunks)app/views/mail/upgradePricingPlanToPower.scala.html(1 hunks)app/views/mail/upgradePricingPlanToTeam.scala.html(1 hunks)app/views/mail/upgradePricingPlanUsers.scala.html(1 hunks)app/views/mail/validateUser.scala.html(1 hunks)app/views/mail/verifyEmail.scala.html(1 hunks)conf/application.conf(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: circleci_build
🔇 Additional comments (33)
app/views/mail/notifyAdminNewUser.scala.html (2)
1-1: LGTM! Clean signature update.The template signature has been correctly updated to include the new
additionalFooterparameter while maintaining backward compatibility by adding it as the last parameter.
3-3: Verify the parameter passing to emailBaseTemplate.The
additionalFooterparameter is correctly passed to the base template. However, let's verify that all callers of this template have been updated to provide this new parameter.✅ Verification successful
Template usage verification completed successfully
The template is only used in
DefaultMails.scalaand correctly includes theadditionalFooterparameter. No other usages were found in the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all usages of notifyAdminNewUser template to verify they provide the additionalFooter parameter # Expected: All calls should include 4 parameters # Search for template usage in Scala files rg -t scala "notifyAdminNewUser" -A 3 # Search for direct template rendering in HTML files rg -t html "notifyAdminNewUser" -A 3Length of output: 323
app/views/mail/upgradePricingPlanToPower.scala.html (2)
1-1: LGTM! Parameter addition aligns with PR objective.The addition of the
additionalFooterparameter to the method signature is clean and follows the PR's goal of making the email footer configurable.
3-3: Verify base template implementation.The
emailBaseTemplateis now receiving theadditionalFooterparameter. Let's verify its implementation to ensure proper handling.✅ Verification successful
Base template implementation verified successfully
The
emailBaseTemplatecorrectly implements and handles theadditionalFooterparameter, rendering it appropriately in the email footer with proper HTML escaping. The implementation is consistent with its usage across all email templates.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify emailBaseTemplate implementation and usage # Check if emailBaseTemplate properly handles the additionalFooter parameter # Find the base template implementation fd -e scala.html emailBaseTemplate # Check all email templates for consistent usage rg -l "emailBaseTemplate.*additionalFooter" --type htmlLength of output: 1085
Script:
#!/bin/bash # Check the implementation of emailBaseTemplate cat app/views/mail/emailBaseTemplate.scala.htmlLength of output: 2187
app/views/mail/jobSuccessfulUploadConvert.scala.html (3)
1-1: LGTM! Template signature updated correctly.The addition of the
additionalFooterparameter aligns with the PR objective and follows proper typing conventions.
3-3: LGTM! Base template integration is correct.The
additionalFooterparameter is properly passed to the base template, ensuring consistent footer rendering.
Line range hint
1-47: Verify consistent implementation across email templates.Let's ensure this change is consistently implemented across all email templates and properly documented.
✅ Verification successful
Implementation is consistent across all email templates ✓
The
additionalFooterparameter is uniformly implemented across all 22 email templates, with each template correctly passing it to the base template where it's properly rendered.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for consistent implementation across email templates echo "Checking email templates for additionalFooter parameter..." rg -t html "additionalFooter" app/views/mail/ # Check for configuration documentation echo "Checking configuration documentation..." fd -t f -e conf -e md . | xargs rg "mail\.additionalFooter"Length of output: 5114
app/views/mail/passwordChanged.scala.html (4)
1-1: LGTM! Parameter addition aligns with PR objectives.The new
additionalFooterparameter is well-named and properly typed for HTML content.
Line range hint
5-14: LGTM! Email content follows security best practices.The template includes essential elements:
- Personal greeting
- Clear action statement
- Security warning for unauthorized changes
- Professional closing
Line range hint
1-14: Verify HTML escaping for additionalFooter content.Since
additionalFootercan contain HTML content, ensure proper HTML escaping is implemented where the configuration is read to prevent XSS attacks.✅ Verification successful
HTML content is automatically escaped by Play Framework's template engine.
The template is using Play Framework's Twirl engine which automatically escapes HTML content by default. The
additionalFooterparameter is processed through the template engine's built-in safety mechanisms, providing protection against XSS attacks.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for configuration reading and HTML escaping rg -l "Mail.additionalFooter" .Length of output: 61
Script:
#!/bin/bash # Check the implementation in DefaultMails.scala rg -A 10 "Mail.additionalFooter" ./app/mail/DefaultMails.scala # Also check for any HTML escaping utilities ast-grep --pattern 'Html.$_($$$)'Length of output: 598
3-3: Verify the base template implementation.The
additionalFooteris passed toemailBaseTemplate. Let's verify its implementation.✅ Verification successful
Base template implementation verified successfully
The
emailBaseTemplatecorrectly implements and uses theadditionalFooterparameter in the footer section of the email template.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for emailBaseTemplate definition and its usage ast-grep --pattern 'def emailBaseTemplate($$$) = { $$$ }' # Also check for other email templates to ensure consistent usage fd -e scala.html . app/views/mail/ --exec grep -l "emailBaseTemplate"Length of output: 1078
Script:
#!/bin/bash # Try to find the base template file fd emailBaseTemplate # Look for the template content in all scala files rg -l "emailBaseTemplate" --type scala # Check how other templates use it (sample a few) head -n 5 app/views/mail/verifyEmail.scala.html head -n 5 app/views/mail/resetPassword.scala.html head -n 5 app/views/mail/invite.scala.htmlLength of output: 717
Script:
#!/bin/bash # View the base template implementation cat app/views/mail/emailBaseTemplate.scala.htmlLength of output: 2187
app/utils/WkConf.scala (1)
157-157: Consider HTML sanitization for footer content.The footer content from configuration is used directly in email templates. Consider sanitizing the HTML content to prevent potential XSS vulnerabilities if the configuration is sourced from user input or external systems.
app/mail/DefaultMails.scala (1)
17-17: LGTM: Consistent implementation of footer configuration.The footer configuration is properly initialized from the injected configuration and consistently used across all email templates.
app/views/mail/extendPricingPlan.scala.html (1)
1-3: LGTM: Proper template parameter handling.The template correctly accepts and passes the footer parameter to the base template.
app/views/mail/upgradePricingPlanToTeam.scala.html (1)
1-1: LGTM! Parameter addition is consistent.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
app/views/mail/help.scala.html (2)
1-1: LGTM! Parameter addition is consistent.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
Line range hint
10-10: Verify URL encoding for XSS protection.The
currentUrlis directly embedded in the template. Ensure it's properly encoded to prevent XSS attacks.✅ Verification successful
Default HTML escaping is active and sufficient for XSS protection.
The
currentUrlis automatically HTML-escaped by Play Framework's template engine (Twirl). The@{currentUrl}syntax maintains the default escaping behavior, making it safe against XSS attacks. No additional encoding is required.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for URL encoding/escaping utilities in the codebase rg -l "encode.*URL|escape.*HTML" --type scalaLength of output: 47
Script:
#!/bin/bash # Search for template configuration and raw HTML markers rg -g "*.scala*" -i "(HtmlFormat|Html|raw|escape)" # Search for currentUrl definition and usage rg -g "*.scala*" "currentUrl" # Search for play.api.templates configuration rg -g "*.conf" "play.api.templates"Length of output: 45981
app/views/mail/notifyAdminNewOrganization.scala.html (2)
1-1: LGTM! Parameter addition is consistent.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
Line range hint
6-8: Verify HTML escaping for user inputs.The template includes user-provided data (
creatorMail,organizationName,domain). Ensure these values are properly HTML escaped to prevent XSS attacks.✅ Verification successful
Play Framework automatically handles HTML escaping
The template is using Play Framework's Twirl engine, which automatically HTML-escapes all dynamic content by default. The
@variablesyntax used forcreatorMail,organizationName, anddomainensures they are properly escaped to prevent XSS attacks. No additional escaping is required.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for HTML escaping mechanisms in the codebase rg -l "escape.*HTML|sanitize.*HTML" --type scalaLength of output: 50
Script:
#!/bin/bash # Search for Play Framework template configurations and HTML escaping related code rg -l "play.twirl|escape|sanitize|XSS" --type-add 'conf:*.conf' --type conf --type scala # Search for similar template patterns to understand the convention fd -e scala.html --exec grep -l "@[a-zA-Z]" {} \; # Look for any security related configurations fd "application.conf" --exec grep -i "play.*security" {} \;Length of output: 1727
app/views/mail/validateUser.scala.html (2)
1-1: LGTM! Parameter addition is consistent.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
Line range hint
10-10: Verify URI encoding for security.Since this is a critical user activation email, ensure the URI is properly encoded and validated before inclusion in the template.
✅ Verification successful
URI handling is properly secured
The URI is securely handled through:
- Play Framework's automatic HTML escaping in templates
- URL validation via java.net.URL
- Secure token generation through the Silhouette authentication framework
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for URI/URL validation and encoding mechanisms rg -l "validate.*URI|encode.*URI|validate.*URL|encode.*URL" --type scalaLength of output: 176
Script:
#!/bin/bash # Search for email validation and activation related files rg -l "validateUser|activat.*user|email.*validation" --type scala # Search for URL/URI construction patterns in scala files rg -B 2 -A 2 "new URI|new URL|URI\.create|URL\.create" --type scala # Find where the validateUser template is used rg -l "validateUser" --type scalaLength of output: 15302
Script:
#!/bin/bash # Check URI construction in UserTokenController and DefaultMails rg -A 5 -B 5 "validateUser.*uri|validateUser.*URL" app/controllers/UserTokenController.scala app/mail/DefaultMails.scala # Look for email validation token generation rg -A 5 -B 5 "createValidationToken|generateToken" app/models/user/UserService.scala app/controllers/UserTokenController.scalaLength of output: 1910
app/views/mail/upgradePricingPlanUsers.scala.html (1)
1-1: LGTM! Parameter addition is consistent.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
app/views/mail/upgradePricingPlanStorage.scala.html (1)
1-3: Verify HTML sanitization for additionalFooter parameterThe additionalFooter parameter contains HTML content that will be injected into emails. Need to ensure proper HTML sanitization is implemented in emailBaseTemplate to prevent potential security vulnerabilities.
✅ Verification successful
HTML rendering is intentionally configured for trusted content
The
additionalFooterparameter is explicitly wrapped with Play Framework'sHtml()helper to render trusted HTML content. This is consistent with Play Framework's type-safe templating system where HTML content is handled explicitly. The parameter is used in the footer section of emails, which is a controlled environment where the content is provided by the application itself, not by end users.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for HTML sanitization in emailBaseTemplate rg -A 5 "def emailBaseTemplate.*additionalFooter" app/views/mail/Length of output: 67
Script:
#!/bin/bash # Find the base template file fd -e scala.html emailBaseTemplate app/views/mail/ # If found, show its content fd -e scala.html emailBaseTemplate app/views/mail/ -x cat {}Length of output: 2299
app/views/mail/upgradePricingPlanRequest.scala.html (1)
1-3: Verify footer HTML doesn't interfere with email linksThe template contains email links (
mailto:). Ensure that the additionalFooter HTML content cannot break or interfere with these links.app/views/mail/resetPassword.scala.html (1)
1-3:⚠️ Potential issueEnsure footer doesn't compromise password reset security
This template handles sensitive password reset functionality. The additionalFooter HTML content should be positioned and sanitized to prevent any interference with the reset token or link.
✅ Verification successful
Footer implementation is secure
The additionalFooter is properly isolated from the password reset functionality:
- Footer content is rendered well below the reset link with clear visual separation
- Reset token is only used as a URL parameter and cannot be affected by footer content
- Template maintains proper structural boundaries between main content and footer
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify placement of additionalFooter in final email rg -A 10 "additionalFooter.*reset.*password" app/views/mail/Length of output: 62
Script:
#!/bin/bash # Get emailBaseTemplate implementation ast-grep --pattern 'emailBaseTemplate($$$) { $$$ }' # Get full content of resetPassword template cat app/views/mail/resetPassword.scala.html # Look for any HTML sanitization utilities rg -g '*.scala' 'HtmlFormat|escape|sanitize'Length of output: 3860
Script:
#!/bin/bash # Find emailBaseTemplate implementation fd emailBaseTemplate.scala # Backup search in case of different extension fd emailBaseTemplateLength of output: 139
Script:
#!/bin/bash # Get emailBaseTemplate implementation cat app/views/mail/emailBaseTemplate.scala.htmlLength of output: 2187
app/views/mail/invite.scala.html (1)
3-3: Verify footer placement relative to invite linkEnsure the additionalFooter HTML content is properly positioned and cannot interfere with the organization invite link and token.
app/views/mail/notifyAdminTimeLimit.scala.html (1)
1-1: LGTM! Parameter addition is consistent with requirements.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
app/views/mail/verifyEmail.scala.html (1)
1-1: LGTM! Parameter addition is consistent with requirements.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
app/views/mail/jobFailedGeneric.scala.html (1)
1-1: LGTM! Parameter addition is consistent with requirements.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
app/views/mail/jobSuccessfulGeneric.scala.html (1)
1-1: LGTM! Parameter addition is consistent with requirements.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
app/views/mail/jobFailedUploadConvert.scala.html (2)
1-1: LGTM! Parameter addition is consistent with requirements.The addition of the
additionalFooterparameter and its usage inemailBaseTemplateis implemented correctly.Also applies to: 3-3
1-1: Verify complete implementation across the codebase.Let's ensure all email templates have been updated consistently and the configuration is properly implemented.
Run this script to verify the implementation:
✅ Verification successful
Implementation verified across all email templates ✓
All 22 email templates consistently implement the
additionalFooterparameter, and the base template correctly renders it in the footer section.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify email template implementations and configuration # Check if any email templates are missing the additionalFooter parameter echo "Checking for email templates missing additionalFooter parameter..." fd -e scala.html . app/views/mail/ --exec grep -L "additionalFooter: String" # Check emailBaseTemplate implementation echo "Checking emailBaseTemplate implementation..." fd -g "emailBaseTemplate.scala.html" . app/views/mail/ --exec cat # Check configuration definition echo "Checking mail configuration..." fd -g "*.conf" . conf/ --exec grep -l "mail.additionalFooter"Length of output: 4795
Script:
#!/bin/bash # First, let's list all email templates echo "Listing all email templates..." fd -e scala.html . app/views/mail/ # Then, let's do a broader search for mail configuration echo -e "\nSearching for mail configuration..." rg -l "mail\." conf/Length of output: 1420
Script:
#!/bin/bash # Check all email templates for additionalFooter parameter echo "Checking email templates for additionalFooter parameter..." fd -e scala.html . app/views/mail/ -x grep -l "additionalFooter: String" {} # Look for mail configuration in common config files echo -e "\nChecking common configuration files..." fd -g "application.conf" -g "reference.conf" . conf/ --exec grep -A 5 "mail\." {}Length of output: 1433
app/views/mail/emailBaseTemplate.scala.html (1)
1-1: LGTM: Parameter addition is clean and well-placed.The new parameter is appropriately added to the template signature.
Good catch. I think you are right. Please conenct/change this line. The email template was probably overlooked. |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
app/controllers/OrganizationController.scala(1 hunks)app/mail/DefaultMails.scala(8 hunks)conf/application.conf(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- conf/application.conf
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: circleci_build
🔇 Additional comments (3)
app/controllers/OrganizationController.scala (1)
215-215: LGTM! Fixed the email template usage.The change correctly uses
upgradePricingPlanToPowerMailfor non-Team plans, addressing the discussion in PR comments about the unused email template.app/mail/DefaultMails.scala (2)
17-17: LGTM! Clean implementation of configurable footer.The private val is correctly initialized from the configuration, making the footer content configurable as intended.
28-28: LGTM! Consistent implementation across all email templates.The additionalFooter parameter has been systematically added to all email templates, ensuring a uniform approach to footer customization throughout the application.
Also applies to: 36-37, 45-45, 50-55, 58-63, 69-69, 77-77, 90-91, 100-100, 108-108, 116-124, 132-132, 140-140, 151-152, 165-167, 175-175, 187-187, 195-195, 203-203, 214-214
| @@ -14,6 +14,7 @@ class DefaultMails @Inject()(conf: WkConf) { | |||
| private val uri = conf.Http.uri | |||
| private val defaultSender = conf.Mail.defaultSender | |||
| private val newOrganizationMailingList = conf.WebKnossos.newOrganizationMailingList | |||
| private val additionalFooter = conf.Mail.additionalFooter | |||
There was a problem hiding this comment.
💡 Codebase verification
Consider adding tests for the footer configuration
The codebase appears to lack dedicated tests for email templates. Since this change affects all email templates through configuration, adding tests would help ensure the footer functionality works correctly across the application.
Key areas to test:
- Configuration loading and parsing
- Footer inclusion in email templates
- Proper HTML rendering with the footer
🔗 Analysis chain
Consider adding tests for the footer configuration.
Since this change affects all email templates, it would be valuable to add tests verifying that:
- The footer content is correctly read from the configuration
- The footer is properly included in the generated email HTML
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any existing tests for email templates
rg -l "test.*Mail" "test/"
Length of output: 26
Script:
#!/bin/bash
# Search for test files in various common test directories with different patterns
fd -t f "test" -t f "spec"
# Search for email-related code to understand the implementation structure
rg -l "Mail" --type scala
Length of output: 957
Script:
#!/bin/bash
# Search for test files in the correct Play Framework test directory
fd . "test" -t d
# Search for any file containing both "test" and "mail" (case insensitive)
rg -i -l "test.*mail|mail.*test"
# Look for test configurations that might contain email settings
rg -l "mail" "conf/test" "conf/application.test" "conf/application.conf"
Length of output: 325
New config option
mail.additionalFooterto supply a html line for the email template.The old behavior can be restored with
mail.additionalFooter = """<a href="https://webknossos.org" style="color: #888;">webknossos.org</a> is a service by <a href="https://scalableminds.com">scalable minds</a> • <a href="mailto:hello@webknossos.org" style="color: #888;">hello@webknossos.org</a>"""Steps to test:
mail.additionalFooter, setmail.logToStdout = true, register new user, see backend logging for full email content.Issues: