19846 implement basic email notifications #167
Conversation
WalkthroughThe changes introduce new email functionality to the project, primarily through the addition of a new dependency in Changes
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 50
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (15)
- build.gradle (1 hunks)
- src/main/java/io/kontur/disasterninja/config/MailSenderConfiguration.java (1 hunks)
- src/main/java/io/kontur/disasterninja/dto/EmailDto.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/NotificationService.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java (2 hunks)
- src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/email/EmailNotificationService.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/slack/SlackMessageFormatter.java (2 hunks)
- src/main/java/io/kontur/disasterninja/notifications/slack/SlackNotificationService.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/slack/SlackSender.java (1 hunks)
- src/main/java/io/kontur/disasterninja/util/FormatUtil.java (1 hunks)
- src/main/resources/notification/gg-email-template.html (1 hunks)
- src/main/resources/notification/gg-email-template.txt (1 hunks)
🧰 Additional context used
🔇 Additional comments (19)
src/main/java/io/kontur/disasterninja/dto/EmailDto.java (1)
1-12: Verify email template integrationSince this DTO will be used with email templates (as mentioned in the PR summary), we should verify the template integration.
✅ Verification successful
Let me analyze the email template integration further by checking the content of the template file and the email formatter class.
This will help us understand how the EmailDto is integrated with the template system.
Let me check how the EmailDto is actually used in the codebase and how it's connected to the template processing.
This will help us understand the complete flow of email processing and how EmailDto fits into it.
Email template integration is properly implemented
The verification shows that EmailDto is correctly integrated with the email template system:
- The HTML template (
gg-email-template.html) exists and contains proper placeholdersEmailMessageFormatterloads and processes the template, creating anEmailDtowith subject, text, and HTML contentEmailSendercorrectly uses the EmailDto fields to send emails via JavaMailSender- Complete flow is orchestrated by
EmailNotificationServiceThe implementation follows a clean separation of concerns:
- Template loading and formatting (EmailMessageFormatter)
- Email sending (EmailSender)
- Orchestration (EmailNotificationService)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for email templates and their usage with EmailDto # Look for template files echo "Checking for email templates..." fd -e html -e ftl -e vm -e mustache # Look for template engine configuration echo -e "\nChecking for template engine configuration..." rg -l "spring\..*template" --type properties --type yaml # Look for template processing code echo -e "\nChecking for template processing code..." rg -l "Template|template" --type javaLength of output: 2166
Script:
#!/bin/bash # Check email template content and formatter implementation echo "Email template content:" cat src/main/resources/notification/gg-email-template.html echo -e "\nEmail formatter implementation:" rg -A 10 "class EmailMessageFormatter" src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.javaLength of output: 2073
Script:
#!/bin/bash # Search for EmailDto usage and email-related code echo "Searching for EmailDto usage:" rg -A 10 "EmailDto" echo -e "\nChecking email formatter methods:" rg -A 20 "format.*Email" src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.java echo -e "\nChecking for email sending implementation:" rg -A 10 "send.*Email|email.*send" --type javaLength of output: 12451
src/main/java/io/kontur/disasterninja/util/FormatUtil.java (1)
1-17: Verify format pattern meets all email notification requirementsLet's verify the usage of this utility and ensure the format pattern "#,###.##" meets all requirements for email notifications.
✅ Verification successful
Let me gather more information about how FormatUtil is being used in the email and slack formatters, and check the analytics service usage to understand if the format patterns are consistent.
Let me check how these formatters actually use FormatUtil in their implementation to ensure the format pattern is appropriate for all cases.
Based on the gathered information, I can now provide a final response:
Format pattern is appropriate for all notification use cases
The "#,###.##" format pattern in FormatUtil is verified to be suitable for all its usages:
- It's used consistently for formatting various numerical metrics in both email and Slack notifications:
- Area measurements (km²)
- Population counts
- Percentages
- Forest/industrial areas
- OSM quality metrics
The same pattern is also used in AnalyticsService, maintaining consistency across the application. The format supports both whole numbers (automatically dropping unnecessary decimals) and decimal values where needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Find all usages of FormatUtil to verify the format pattern meets requirements echo "Searching for FormatUtil usage..." rg -l "FormatUtil" # Look for other number formatting patterns in the codebase echo "Checking for other number formatting patterns..." rg "new DecimalFormat\(" # Check email templates for number formatting echo "Checking email templates..." fd -e html -e ftl -e templateLength of output: 976
Script:
#!/bin/bash # Check how FormatUtil is used in email and slack formatters echo "EmailMessageFormatter usage:" rg -A 5 "FormatUtil" src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.java echo -e "\nSlackMessageFormatter usage:" rg -A 5 "FormatUtil" src/main/java/io/kontur/disasterninja/notifications/slack/SlackMessageFormatter.java echo -e "\nAnalyticsService number formatting usage:" rg -A 5 "numberFormat" src/main/java/io/kontur/disasterninja/service/AnalyticsService.java echo -e "\nChecking email template for number placeholders:" cat src/main/resources/notification/gg-email-template.htmlLength of output: 3646
Script:
#!/bin/bash # Check the actual usage of formatNumber in the formatters echo "EmailMessageFormatter implementation:" ast-grep --pattern 'formatNumber($_)' echo -e "\nCheck for variable assignments and method calls in EmailMessageFormatter:" rg -A 5 "= format" src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.java echo -e "\nCheck for variable assignments and method calls in SlackMessageFormatter:" rg -A 5 "= format" src/main/java/io/kontur/disasterninja/notifications/slack/SlackMessageFormatter.javaLength of output: 7830
src/main/resources/notification/gg-email-template.txt (2)
15-16: Specify date format for consistency.The dates should follow a consistent, unambiguous format. Consider using ISO 8601 or specifying the timezone for clarity.
6-9: 🧹 Nitpick (assertive)Add units formatting for better readability.
The numerical values should be properly formatted with thousands separators and consistent decimal places for better readability.
Let's verify how these values are formatted in the code:
src/main/java/io/kontur/disasterninja/notifications/slack/SlackSender.java (1)
1-33: Verify Slack notification configuration across environmentsSince this is a new notification system, we should ensure proper configuration across different environments.
Let's check for any existing Slack-related configurations:
src/main/java/io/kontur/disasterninja/notifications/slack/SlackNotificationService.java (1)
14-14: Verify integration with email notification system.Since this PR implements email notifications, let's verify how this Slack service integrates with the new email notification system.
✅ Verification successful
Let me gather more information about how these notification services are used together.
Let me check one final aspect about how these services are configured and initialized.
Based on the gathered information, I can now provide the final response:
Integration with email notification system is properly implemented
The codebase shows a well-structured notification system where:
- Both
SlackNotificationServiceandEmailNotificationServiceextend the same abstractNotificationServiceclass- All notification components are consistently configured with
@ConditionalOnProperty(value = "notifications.enabled")- The notification services share common validation logic through the base class (event type, severity, and populated area checks)
- Each service has its own dedicated formatter and sender components following the same pattern
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for parallel email notification service implementation and common parent class usage # Test 1: Look for email notification service implementation echo "Checking for email notification service implementation..." rg -l "class \w*EmailNotification\w*Service\b.*extends NotificationService" # Test 2: Check NotificationService usage echo "Checking NotificationService usage in notification processor..." ast-grep --pattern 'class $_ { $$$ private List<NotificationService> $_ = $_ $$$ }'Length of output: 519
Script:
#!/bin/bash # Check the implementation details and usage patterns # Look at NotificationService base class echo "Checking NotificationService base class..." rg -A 10 "^public\s+(abstract\s+)?class\s+NotificationService\b" # Look for where multiple notification services are used together echo "Checking for notification service usage patterns..." rg -A 5 "NotificationService.*[;=]" # Look specifically at how EmailNotificationService is implemented echo "Checking EmailNotificationService implementation..." rg -A 10 "class EmailNotificationService extends NotificationService"Length of output: 7264
Script:
#!/bin/bash # Check configuration and initialization # Look for configuration properties and conditional initialization echo "Checking conditional properties for both services..." rg -B 2 -A 1 "@ConditionalOnProperty.*notification" # Check NotificationsProcessor constructor to see how services are injected echo "Checking NotificationsProcessor constructor..." rg -A 10 "NotificationsProcessor\([^)]*NotificationService"Length of output: 4715
src/main/java/io/kontur/disasterninja/notifications/email/EmailNotificationService.java (2)
17-17: LGTM!Logger is properly configured following best practices.
1-39: Verify integration with notification systemLet's verify several aspects of the implementation:
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java (1)
1-15: LGTM! Well-structured class declaration with appropriate conditional loading.The class follows Spring best practices with proper component scanning and conditional property-based initialization.
build.gradle (1)
60-62: LGTM! Spring Boot Mail Starter dependency added correctly.The dependency is properly placed and will be version-managed through the Spring Boot dependency management plugin.
src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.java (3)
1-36: LGTM! Well-structured class setup with proper dependency injection.The class is properly configured with Spring annotations and follows best practices for logger and formatter initialization.
50-57: LGTM! Robust template loading implementation.The method properly handles resources and provides clear error messages for missing templates.
39-40: Verify the existence of email templates.The code references two template files that need to be present in the classpath.
✅ Verification successful
Since the executed script has provided clear evidence that both required template files exist at the expected locations in the
src/main/resources/notification/directory, I can generate the final response:Template files are present and correctly located
Both required email templates exist in the classpath:
src/main/resources/notification/gg-email-template.txtsrc/main/resources/notification/gg-email-template.html🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the required template files exist echo "Checking for email templates..." fd -t f "gg-email-template" -E "*.class"Length of output: 222
src/main/java/io/kontur/disasterninja/notifications/NotificationService.java (1)
39-41: Verify the logic for filtering events based on severity.The method
isEventSeverityAppropriatefilters out events whose names start with "Green." Ensure that this logic aligns with the desired behavior for event severity filtering.Run the following script to check for events starting with "Green" and review their handling:
✅ Verification successful
Let me gather more context about this event filtering logic to understand its purpose and implementation better.
Let me gather one final piece of information to understand the complete notification flow.
Based on the gathered information, I can now provide a final response about the event severity filtering logic.
The event severity filtering implementation is correct and intentional
The
isEventSeverityAppropriatemethod is part of a broader notification filtering system that works in conjunction with theMessageFormatterclass. The filtering logic specifically excludes events with names starting with "Green" because:
- The codebase shows a consistent color-coding system for event severity levels in
MessageFormatter, where "Green", "Orange", and "Red" represent different severity levels- The
Severityenum shows a proper hierarchy (EXTREME, SEVERE, etc.)- The notification service is designed to filter out lower severity ("Green") events to avoid notification noise for less critical situations
The implementation aligns with the intended behavior of focusing notifications on more severe events.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find events with names starting with 'Green' to verify filtering logic. # Test: Search for event names starting with 'Green'. Expect: Understand how many events are affected. rg 'event.getName\(\).*startsWith\("Green"\)'Length of output: 217
Script:
#!/bin/bash # Search for the usage of isEventSeverityAppropriate method and related event filtering logic rg -A 5 "isEventSeverityAppropriate" # Look for any tests related to this filtering logic fd "Test.*\.java" --exec rg -l "Green" # Search for documentation or comments explaining the severity levels rg -B 2 -A 2 "severity|Severity" --type javaLength of output: 13415
Script:
#!/bin/bash # Look for tests related to NotificationService to understand the expected behavior fd "Test.*\.java" --exec rg -l "NotificationService" # Look for any documentation about notification filtering rg -B 3 -A 3 "isEventSeverityAppropriate|Green" --type java --type mdLength of output: 7450
src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java (2)
50-54: Constructor Injection ConsistencyThe constructor now includes
List<NotificationService> notificationServices. Confirm that the parameter order matches the field assignments and that all dependencies are correctly injected.
45-45: Verify Dependency Injection ofnotificationServicesThe
notificationServiceslist is introduced as a new dependency. Ensure that all implementing classes ofNotificationServiceare properly annotated and recognized by the Spring container for dependency injection to work correctly.To automate this verification, run the following script to list all classes implementing
NotificationService:✅ Verification successful
Let me try a different approach to verify the implementation classes and their Spring annotations.
This should help us find:
- The interface definition
- Any implementing classes even if the pattern is slightly different
- Spring service annotations related to NotificationService implementations
Let me try one final search pattern to locate the interface and implementations.
This broader search should help us locate the relevant files and their Spring configurations.
Spring DI for
notificationServicesis properly configuredBased on the code analysis, the dependency injection for
notificationServicesis correctly set up:
- Found two implementing classes properly annotated with
@Component:
EmailNotificationServiceextendsNotificationServiceSlackNotificationServiceextendsNotificationService- Both implementations are conditionally enabled with
@ConditionalOnProperty(value = "notifications.enabled")- The base
NotificationServiceclass is abstract and also annotated with@Component- Spring's autowiring will correctly inject the list of all implementing services into
NotificationsProcessor's constructor🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: List all classes implementing NotificationService # Expected Result: All implementing classes are listed, confirming proper setup. # Find all Java classes implementing NotificationService rg --multiline --type java 'class\s+\w+\s+implements\s+NotificationService' -lLength of output: 80
Script:
#!/bin/bash # First, let's find the NotificationService interface definition to understand the package rg --type java "interface NotificationService" # Then let's search for classes that might implement it using a broader pattern rg --type java -A 5 "implements.*NotificationService" # Also search for any @Service annotations to find Spring services rg --type java "@Service.*NotificationService"Length of output: 153
Script:
#!/bin/bash # Let's first find all files that might contain NotificationService in their name or content fd NotificationService # Then let's look at the content of any Java files containing NotificationService rg -l "NotificationService" --type java | xargs cat # Also search for potential Spring component annotations more broadly rg -l "@(Service|Component).*class" --type javaLength of output: 11921
src/main/java/io/kontur/disasterninja/notifications/slack/SlackMessageFormatter.java (3)
1-1: Package restructuring aligns with project organizationChanging the package to
io.kontur.disasterninja.notifications.slackimproves the modularity and organization of the Slack notification components within the project.
17-17: ExtendingMessageFormatterenhances code reuseBy extending
MessageFormatter,SlackMessageFormattercan leverage shared formatting logic, promoting code reuse and maintainability.
27-29: 🛠️ Refactor suggestionAdd
@Overrideannotation to theformatmethodThe
formatmethod appears to override a method from the superclassMessageFormatter. Adding the@Overrideannotation improves code clarity and allows the compiler to enforce correct overriding.Apply this diff to add the
@Overrideannotation:+ @Override public String format(EventApiEventDto event, Map<String, Object> urbanPopulationProperties, Map<String, Double> analytics) {Likely invalid or redundant comment.
src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java
Outdated
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/slack/SlackMessageFormatter.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/slack/SlackMessageFormatter.java
Show resolved
Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (1)
- src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java (2 hunks)
🧰 Additional context used
🔇 Additional comments (4)
src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java (4)
45-45: Addition ofnotificationServicesfield looks goodThe new field
notificationServicesis appropriately added to manage multiple notification services.
50-54: Constructor updated to includenotificationServicesThe constructor correctly includes the
notificationServicesparameter to inject the list of notification services.
89-89: Add Error Handling for Notification ProcessingCurrently, if
notificationService.process()throws an exception, it could prevent subsequent services from processing the event and may not updatelatestUpdatedDateappropriately.Consider wrapping the notification processing in a try-catch block to handle exceptions per service without affecting others.
90-90: UpdatelatestUpdatedDateAfter All Services Have ProcessedUpdating
latestUpdatedDateinside the notification service loop may result in advancing the date even if not all services have processed the event. It's better to update it after all services have processed the event.
src/main/java/io/kontur/disasterninja/notifications/NotificationsProcessor.java
Show resolved
Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (2)
- src/main/java/io/kontur/disasterninja/notifications/NotificationService.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java (1 hunks)
🧰 Additional context used
🔇 Additional comments (6)
src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java (5)
22-26: Add configuration validation for sender and recipientsThe email sender and recipients configuration should be validated at component initialization.
28-30: Add constructor parameter validationThe JavaMailSender dependency should be validated in the constructor.
32-47: Enhance error handling and add security measuresThe current implementation needs improvements in several areas:
- Input validation
- Specific exception handling
- Monitoring metrics
- Rate limiting
- Security measures
Additionally, consider implementing batch processing for better performance with large recipient lists.
15-15: 🧹 Nitpick (assertive)Specify matchIfMissing behavior in @ConditionalOnProperty
For better clarity and predictable behavior, explicitly define what happens when the property is missing.
-@ConditionalOnProperty(value = "notifications.enabled") +@ConditionalOnProperty(value = "notifications.enabled", matchIfMissing = false)Likely invalid or redundant comment.
32-47:⚠️ Potential issueImplement security measures to prevent abuse
The current implementation lacks critical security measures:
- No rate limiting to prevent email flooding
- No HTML content sanitization
- No maximum limit on recipients
This could potentially be exploited for spam or denial of service attacks.
Let's verify if there are any rate limiting configurations in the project:
src/main/java/io/kontur/disasterninja/notifications/NotificationService.java (1)
13-13: 🧹 Nitpick (assertive)Consider using a Set for acceptableTypes for better performance
When checking for containment, using a
Setinstead of aListcan improve lookup performance. Although the current list is small, changingacceptableTypesto aSetenhances scalability and readability.Apply this diff:
-private static final List<String> acceptableTypes = Arrays.asList("FLOOD", "EARTHQUAKE", "CYCLONE", "VOLCANO", "WILDFIRE"); +private static final Set<String> acceptableTypes = new HashSet<>(Arrays.asList("FLOOD", "EARTHQUAKE", "CYCLONE", "VOLCANO", "WILDFIRE"));Likely invalid or redundant comment.
src/main/java/io/kontur/disasterninja/notifications/NotificationService.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/NotificationService.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/NotificationService.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java
Outdated
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/email/EmailMessageFormatter.java
Show resolved
Hide resolved
Co-authored-by: Alexander Chichigin <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 8
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (5)
- src/main/java/io/kontur/disasterninja/config/MailSenderConfiguration.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/email/EmailNotificationService.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java (1 hunks)
- src/main/java/io/kontur/disasterninja/notifications/slack/SlackNotificationService.java (1 hunks)
🔇 Additional comments (7)
src/main/java/io/kontur/disasterninja/notifications/email/EmailNotificationService.java (3)
13-14: Strengthen the conditional property configurationThe existing review comment about making the @ConditionalOnProperty configuration more explicit is still valid.
22-25: Add null validation for dependenciesThe existing review comment about adding null checks for dependencies to prevent NullPointerException is still valid.
27-38: Multiple improvements needed in process methodThe existing review comment about multiple improvements including input validation, transaction management, and logging placement is still valid.
src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java (4)
14-15: Specify matchIfMissing behavior in @ConditionalOnPropertyFor better clarity and to avoid ambiguity when the property is not defined, explicitly set the matchIfMissing behavior.
22-26: Add configuration validationThe sender and recipients properties should be validated at component initialization to fail fast if the configuration is invalid.
28-30: Add constructor parameter validationAdd null check for the injected JavaMailSender to fail fast if dependency injection fails.
32-35:⚠️ Potential issueRemove redundant null check
The null check for
javaMailSenderis redundant if proper constructor validation is implemented. Additionally, using a genericRuntimeExceptionis not ideal.- public void send(EmailDto emailDto) { - if (javaMailSender == null) { - throw new RuntimeException("Not able to proceed with email notifications because javaMailSender is not initialized."); - } + public void send(EmailDto emailDto) {Likely invalid or redundant comment.
src/main/java/io/kontur/disasterninja/notifications/email/EmailNotificationService.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/email/EmailSender.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/slack/SlackNotificationService.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/config/MailSenderConfiguration.java
Show resolved
Hide resolved
src/main/java/io/kontur/disasterninja/notifications/MessageFormatter.java
Show resolved
Hide resolved
palina-krukovich
deleted the
19846-implement-basic-email-notifications-in-disaster-ninja-be-for-gg
branch
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Documentation
Chores