feat(j-s): Indictment sent or withdrawn from prison notifications #16943

unakb · 2024-11-19T14:58:21Z

Senda tilkynningu til FMST - fullnusta
Senda tilkynningu til FMST - afturköllun

What

Send notifications to a group of prison admin staff when an indictment is sent or withdrawn .

Why

To let them know that something new has happened in case they need to react to it.

Checklist:

I have performed a self-review of my own code
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
Formatting passes locally with my changes
I have rebased against main before asking for a review

Summary by CodeRabbit

Release Notes

New Features
- Introduced new notification types for indictments related to prison administration.
- Added functionality to send notifications when a defendant is sent to or withdrawn from prison administration.
- New secret added for managing prison administration indictment emails.
Bug Fixes
- Improved handling of notification messages for defendant status changes.
Documentation
- Updated configuration files to include new secret for prison administration email notifications.
Tests
- Added unit tests for new notification functionalities related to indictments.
Chores
- Restructured import paths for better organization within the notification services.

…o-fmst

…o j-s/send-to-fmst

…o-fmst

…ations

coderabbitai

Actionable comments posted: 7

🧹 Outside diff range and nitpick comments (24)

apps/judicial-system/backend/src/app/modules/notification/notification.module.ts (1)

20-24: LGTM! Consider updating documentation.

The reorganization of notification services into a dedicated services directory follows NestJS best practices for module organization and improves code maintainability.

Consider updating the module's documentation to reflect this new directory structure, particularly if there's a README.md file in the notification module.
apps/judicial-system/backend/src/app/modules/notification/services/defendantNotification/defendantNotification.strings.ts (2)
30-41: LGTM! Consider improving type safety for message placeholders.

The implementation follows i18n best practices and maintains consistency with existing patterns. However, consider enhancing type safety by defining TypeScript interfaces for the message placeholders.

Example implementation:
interface IndictmentMessagePlaceholders {
  courtCaseNumber: string;
  linkStart: string;
  linkEnd: string;
}

// Usage
defineMessage<IndictmentMessagePlaceholders>({
  id: 'judicial.system.backend:defendant_notifications.indictment_sent_to_prison_admin_body',
  defaultMessage: '...',
  description: '...',
})
42-54: Consider adding a case overview link for consistency.

For consistency with other notification messages, consider including a link to the case overview in the withdrawal notification body. This would help prison administrators access the case details if needed.

Apply this diff to add the case overview link:
   indictmentWithdrawnFromPrisonAdminBody: defineMessage({
     id: 'judicial.system.backend:defendant_notifications.indictment_withdrawn_from_prison_admin_body',
     defaultMessage:
-      'Ríkissaksóknari hefur afturkallað mál {courtCaseNumber} úr fullnustu.',
+      'Ríkissaksóknari hefur afturkallað mál {courtCaseNumber} úr fullnustu.<br /><br />Sjá nánar á {linkStart}yfirlitssíðu málsins í Réttarvörslugátt{linkEnd}.',
     description:
       'Texti í tilkynningu til FMST þegar mál er afturkallað úr fullnustu',
   }),
libs/judicial-system/types/src/lib/notification.ts (1)
ADVOCATE_ASSIGNED is actively used and requires careful deprecation

The enum value ADVOCATE_ASSIGNED is currently used in multiple critical locations:

Used in notification type definitions

Referenced in case notification service for handling advocate assignment notifications

Active usage in notification service for user-related functionality

Before removal:

Add @deprecated JSDoc comment with migration path

Create tracking issue for coordinated removal

Update all identified usage locations:

apps/judicial-system/backend/src/app/modules/notification/services/caseNotification/caseNotification.service.ts

apps/judicial-system/backend/src/app/modules/notification/notification.service.ts

🔗 Analysis chain

Line range hint 8-8: Consider proper deprecation process for ADVOCATE_ASSIGNED.

Instead of using a comment to indicate future removal, consider:

Adding a proper @deprecated JSDoc comment with migration instructions

Creating a tracking issue for the removal

Ensuring all usages are identified before removal

This helps maintain backward compatibility and provides clear migration paths.

Let's check for existing usage:
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:
#!/bin/bash
# Description: Check for ADVOCATE_ASSIGNED usage in the codebase
# Expected: Find all code that needs to be updated before removal

rg -A 3 "ADVOCATE_ASSIGNED" \
  --type ts \
  --glob '!*.test.ts' \
  --glob '!*.spec.ts'
Length of output: 3888
apps/judicial-system/backend/infra/judicial-system-backend.ts (1)
73-74: Consider adding environment-specific configuration if needed.

If the email recipients differ across environments (dev/staging/prod), consider adding environment-specific configuration in the env section similar to other configurable values.

Example:
 .env({
   // ... existing env vars ...
+  PRISON_ADMIN_INDICTMENT_EMAILS: {
+    dev: '[email protected]',
+    staging: '[email protected]',
+    prod: ref((h) => h.secrets.PRISON_ADMIN_INDICTMENT_EMAILS),
+  },
 })
apps/judicial-system/backend/src/app/modules/notification/test/internalNotificationController/defendantNotification/sendIndictmentWithdrawnFromPrisonAdminNotifications.spec.ts (2)
1-32: Consider reorganizing imports and extracting common test types.

The imports could be better organized, and the test types could be made more reusable.

Consider:

Grouping imports:
// External dependencies
import { uuid } from 'uuidv4'
import { EmailService } from '@island.is/email-service'

// Domain types
import {
  CaseType,
  DefendantNotificationType,
} from '@island.is/judicial-system/types'

// Test utilities
import { createTestingNotificationModule } from '../../createTestingNotificationModule'

// Internal modules
import { Case } from '../../../../case'
import { Defendant } from '../../../../defendant'
import { DefendantNotificationDto } from '../../../dto/defendantNotification.dto'
import { DeliverResponse } from '../../../models/deliver.response'
import { Notification } from '../../../models/notification.model'
Consider moving the Then interface and GivenWhenThen type to a shared test utilities file as they could be reused across similar notification test files.

1-1: Add test file documentation.

Consider adding a descriptive comment block at the beginning of the file to explain:

The purpose of these tests

The requirements being verified

Any specific setup requirements

Example:
/**
 * Tests for prison admin notification functionality when an indictment is withdrawn.
 * 
 * Requirements:
 * - Notifications must be sent to all configured prison admin email addresses
 * - Each notification must include the case number and withdrawal information
 * - All notification attempts must be recorded, whether successful or not
 * 
 * Setup:
 * - Requires PRISON_ADMIN_INDICTMENT_EMAILS environment variable
 * - Uses mocked email service and notification model
 */
apps/judicial-system/backend/src/app/modules/notification/test/internalNotificationController/defendantNotification/sendIndictmentSentToPrisonAdminNotification.spec.ts (3)
21-33: Add JSDoc comments to improve type documentation.

The GivenWhenThen type and Then interface would benefit from JSDoc comments explaining their purpose and usage in the test suite.
+/**
+ * Represents the result of a test case execution
+ */
 interface Then {
   result: DeliverResponse
   error: Error
 }

+/**
+ * Type definition for the Given-When-Then test pattern implementation
+ * @param caseId - The unique identifier of the case
+ * @param defendantId - The unique identifier of the defendant
+ * @param theCase - The case object
+ * @param defendant - The defendant object
+ * @param notificationDto - The notification data transfer object
+ * @returns Promise containing the test result
+ */
 type GivenWhenThen = (
   caseId: string,
   defendantId: string,
   theCase: Case,
   defendant: Defendant,
   notificationDto: DefendantNotificationDto,
 ) => Promise<Then>
37-40: Move test email addresses to constants.

Consider moving the test email addresses to a constants file to improve maintainability and reusability.
+const TEST_PRISON_ADMIN_EMAILS = [
+  '[email protected]',
+  '[email protected]',
+] as const;
-const emails = [
-  '[email protected]',
-  '[email protected]',
-]
+const emails = [...TEST_PRISON_ADMIN_EMAILS]
1-144: Consider simplifying the test file name.

The current file name sendIndictmentSentToPrisonAdminNotification.spec.ts is quite long. Consider a more concise name like prisonAdminIndictment.spec.ts while ensuring it remains descriptive enough to understand its purpose.
charts/services/judicial-system-backend/values.prod.yaml (1)

Line range hint 1-7: Warning: This file should not be edited manually

The file header explicitly states that manual edits should be avoided and yarn charts should be run instead. Please ensure this change was made through the proper workflow.

Consider running yarn charts to regenerate this file instead of manual edits.

charts/services/judicial-system-backend/values.staging.yaml (1)

Line range hint 1-7: Important: Do not edit this file manually.

As indicated by the warning comment, this file is automatically generated. Please ensure you're using yarn charts to make any changes.
apps/judicial-system/backend/src/app/modules/defendant/test/defendantController/update.spec.ts (2)
212-236: Consider enhancing test coverage for prison admin notification.

The test case effectively verifies the basic notification flow. However, consider adding:

A negative test case where CaseType is not INDICTMENT

Verification of the complete message payload structure, including any metadata
 describe('defendant in indictment is sent to prison admin', () => {
+  describe.each([
+    { caseType: CaseType.INDICTMENT, shouldQueue: true },
+    { caseType: CaseType.CUSTODY, shouldQueue: false }
+  ])('when case type is $caseType', ({ caseType, shouldQueue }) => {
     const defendantUpdate = { isSentToPrisonAdmin: true }
     const updatedDefendant = { ...defendant, ...defendantUpdate }

     beforeEach(async () => {
       const mockUpdate = mockDefendantModel.update as jest.Mock
       mockUpdate.mockResolvedValueOnce([1, [updatedDefendant]])

-      await givenWhenThen(defendantUpdate, CaseType.INDICTMENT, caseId)
+      await givenWhenThen(defendantUpdate, caseType, caseId)
     })

-    it('should queue messages', () => {
+    it(shouldQueue ? 'should queue messages' : 'should not queue messages', () => {
+      if (shouldQueue) {
         expect(mockMessageService.sendMessagesToQueue).toHaveBeenCalledWith([
           {
             type: MessageType.DEFENDANT_NOTIFICATION,
             caseId,
             elementId: defendantId,
             body: {
               type: DefendantNotificationType.INDICTMENT_SENT_TO_PRISON_ADMIN,
             },
+            metadata: expect.any(Object)
           },
         ])
         expect(mockMessageService.sendMessagesToQueue).toHaveBeenCalledTimes(1)
+      } else {
+        expect(mockMessageService.sendMessagesToQueue).not.toHaveBeenCalled()
+      }
     })
+  })
 })
238-262: Improve test name and coverage for withdrawal notification.

The test case effectively verifies the withdrawal notification. Consider:

Making the test description more concise by removing redundant "for indictment withdrawn from prison admin"

Adding test cases for non-INDICTMENT case types similar to the previous test
 describe('defendant in indictment is withdrawn from prison admin', () => {
+  describe.each([
+    { caseType: CaseType.INDICTMENT, shouldQueue: true },
+    { caseType: CaseType.CUSTODY, shouldQueue: false }
+  ])('when case type is $caseType', ({ caseType, shouldQueue }) => {
     const defendantUpdate = { isSentToPrisonAdmin: false }
     const updatedDefendant = { ...defendant, ...defendantUpdate }

     beforeEach(async () => {
       const mockUpdate = mockDefendantModel.update as jest.Mock
       mockUpdate.mockResolvedValueOnce([1, [updatedDefendant]])

-      await givenWhenThen(defendantUpdate, CaseType.INDICTMENT, caseId)
+      await givenWhenThen(defendantUpdate, caseType, caseId)
     })

-    it('should queue messages for indictment withdrawn from prison admin', () => {
+    it(shouldQueue ? 'should queue messages' : 'should not queue messages', () => {
+      if (shouldQueue) {
         expect(mockMessageService.sendMessagesToQueue).toHaveBeenCalledWith([
           {
             type: MessageType.DEFENDANT_NOTIFICATION,
             caseId,
             elementId: defendantId,
             body: {
               type: DefendantNotificationType.INDICTMENT_WITHDRAWN_FROM_PRISON_ADMIN,
             },
+            metadata: expect.any(Object)
           },
         ])
         expect(mockMessageService.sendMessagesToQueue).toHaveBeenCalledTimes(1)
+      } else {
+        expect(mockMessageService.sendMessagesToQueue).not.toHaveBeenCalled()
+      }
     })
+  })
 })
apps/judicial-system/backend/src/app/modules/defendant/defendant.service.ts (2)
77-95: Consider enhancing type safety and method naming

The implementation is clean and follows a consistent pattern, but could benefit from these improvements:
- private getMessagesForIndictmentToPrisonAdminChanges(
-   defendant: Defendant,
- ): Message {
+ private getIndictmentPrisonAdminMessage(
+   defendant: Defendant,
+ ): DefendantNotificationMessage {
Consider creating a type for notification messages to enhance type safety:
type DefendantNotificationMessage = Message & {
  type: MessageType.DEFENDANT_NOTIFICATION;
  body: {
    type: DefendantNotificationType;
  };
};
Line range hint 166-207: Consider splitting responsibilities and improving error handling

The method is handling multiple notification types which increases complexity. Consider refactoring for better separation of concerns.
- private async sendIndictmentCaseUpdateDefendantMessages(
+ private async sendDefenderChoiceNotification(
   theCase: Case,
   updatedDefendant: Defendant,
   oldDefendant: Defendant,
   user: User,
-): Promise<void> {
+): Promise<Message[]> {
   if (!theCase.courtCaseNumber) {
-    return
+    return []
   }

   const messages: Message[] = []
   
   if (updatedDefendant.isDefenderChoiceConfirmed && 
       !oldDefendant.isDefenderChoiceConfirmed) {
     // ... defender choice logic ...
   }
   
   return messages
}

+ private async sendPrisonAdminNotification(
+   theCase: Case,
+   updatedDefendant: Defendant,
+   oldDefendant: Defendant,
+ ): Promise<Message[]> {
+   if (!theCase.courtCaseNumber) {
+     return []
+   }
+   
+   const messages: Message[] = []
+   
+   if (this.hasPrisonAdminStatusChanged(updatedDefendant, oldDefendant)) {
+     messages.push(
+       this.getIndictmentPrisonAdminMessage(updatedDefendant),
+     )
+   }
+   
+   return messages
+ }

+ private hasPrisonAdminStatusChanged(
+   updatedDefendant: Defendant,
+   oldDefendant: Defendant,
+ ): boolean {
+   return updatedDefendant.isSentToPrisonAdmin !== undefined &&
+          updatedDefendant.isSentToPrisonAdmin !== oldDefendant.isSentToPrisonAdmin
+ }

+ private async sendIndictmentCaseUpdateDefendantMessages(
+   theCase: Case,
+   updatedDefendant: Defendant,
+   oldDefendant: Defendant,
+   user: User,
+ ): Promise<void> {
+   try {
+     const messages = [
+       ...(await this.sendDefenderChoiceNotification(theCase, updatedDefendant, oldDefendant, user)),
+       ...(await this.sendPrisonAdminNotification(theCase, updatedDefendant, oldDefendant)),
+     ]
+     
+     if (messages.length > 0) {
+       await this.messageService.sendMessagesToQueue(messages)
+     }
+   } catch (error) {
+     this.logger.error('Failed to send indictment case update notifications', {
+       error,
+       caseId: theCase.id,
+       defendantId: updatedDefendant.id,
+     })
+     throw error
+   }
+ }
charts/judicial-system/values.dev.yaml (1)

Line range hint 89-93: Review the impact of reduced nginx request rate

The nginxRequestsIrate metric for HPA scaling has been reduced from 8 to 5, which might affect the scaling behavior of the backend service. This change could impact the system's ability to handle traffic spikes.

Consider the following recommendations:

Document the reasoning behind this reduction in the PR description

Monitor the scaling behavior after deployment to ensure it meets performance requirements

Consider implementing a gradual reduction if this is a significant change for production
apps/judicial-system/backend/src/app/modules/notification/services/caseNotification/caseNotification.service.ts (5)
Line range hint 1-84: Consider reorganizing imports for better maintainability

The imports could be better organized by grouping them into the following categories:

Node built-in modules

External dependencies (nest, lodash, etc.)

Internal modules

Types and interfaces
+ // Node built-in modules
+
+ // External dependencies
import { ICalendar } from 'datebook'
import _uniqBy from 'lodash/uniqBy'
import {
  Inject,
  Injectable,
  InternalServerErrorException,
} from '@nestjs/common'
import { InjectModel } from '@nestjs/sequelize'
+
+ // Internal modules
import { IntlService } from '@island.is/cms-translations'
...
+
+ // Types and interfaces
import {
  CaseAppealRulingDecision,
  CaseCustodyRestrictions,
  ...
} from '@island.is/judicial-system/types'
Line range hint 92-99: Enhance error handling in sendSms method

The error handling in the catch block could be improved by:

Adding more context to the error message

Including the SMS text in the error event for better debugging

Considering retrying failed SMS sends for critical notifications
  } catch (reason) {
-   this.logger.error('Failed to send sms', { error: reason })
+   this.logger.error('Failed to send SMS notification', {
+     error: reason,
+     mobileNumbers,
+     smsText: smsText.substring(0, 100), // Truncate for logging
+     notificationType: 'SMS'
+   })

    this.eventService.postErrorEvent(
-     'Failed to send sms',
-     { mobileNumbers },
+     'Failed to send SMS notification',
+     { mobileNumbers, notificationType: 'SMS' },
      reason,
    )
Line range hint 1024-1039: Enhance security for sensitive data handling

The email content construction should:

Sanitize HTML content to prevent XSS

Redact sensitive information in logs

Consider adding rate limiting for notifications to prevent abuse
+ import { sanitizeHtml } from '@island.is/judicial-system/utils'

  private async sendRulingEmailNotificationToProsecutor(
    theCase: Case,
  ): Promise<Recipient> {
+   // Sanitize HTML content
+   const sanitizedHtml = sanitizeHtml(
+     isIndictmentCase(theCase.type)
+       ? this.formatMessage(notifications.caseCompleted.prosecutorBody, {
+           courtCaseNumber: theCase.courtCaseNumber,
+           courtName: theCase.court?.name?.replace('dómur', 'dómi'),
+           ...
+         })
+       : this.formatMessage(notifications.signedRuling.prosecutorBodyS3, {
+           ...
+         })
+   )

    return this.sendEmail(
      subject,
-     html,
+     sanitizedHtml,
      theCase.prosecutor?.name,
      theCase.prosecutor?.email,
    )
  }
Line range hint 1583-1612: Optimize notification sending with batching

The sendNotification method could be optimized by:

Implementing batch sending for multiple recipients

Caching frequently used email templates

Adding retry mechanisms with exponential backoff
+ private async batchSendEmails(
+   recipients: Array<{ email: string; name: string }>,
+   subject: string,
+   template: string,
+   attachments?: Attachment[],
+ ): Promise<Recipient[]> {
+   // Implement batched email sending
+   return this.emailService.sendBatch(recipients, subject, template, attachments);
+ }

  private async sendRulingNotifications(
    theCase: Case,
  ): Promise<DeliverResponse> {
-   const promises = [this.sendRulingEmailNotificationToProsecutor(theCase)]
+   const recipients = [{
+     email: theCase.prosecutor?.email,
+     name: theCase.prosecutor?.name,
+   }]

    if (isIndictmentCase(theCase.type)) {
      const uniqueDefendants = _uniqBy(
        theCase.defendants ?? [],
        (d: Defendant) => d.defenderEmail,
      )
-     uniqueDefendants.forEach((defendant) => {
+     recipients.push(...uniqueDefendants.map(defendant => ({
+       email: defendant.defenderEmail,
+       name: defendant.defenderName,
+     })))
-       if (defendant.defenderEmail) {
-         promises.push(
-           this.sendRulingEmailNotificationToDefender(
-             theCase,
-             defendant.defenderNationalId,
-             defendant.defenderName,
-             defendant.defenderEmail,
-           ),
-         )
-       }
-     })
    }

+   const batchResults = await this.batchSendEmails(
+     recipients.filter(r => r.email),
+     subject,
+     template,
+   )
Line range hint 1-1700: Consider splitting the service into smaller, focused services

The CaseNotificationService has grown quite large and handles multiple responsibilities. Consider:

Extracting email and SMS sending logic into separate services

Creating separate services for different notification types (appeal, ruling, etc.)

Implementing a notification factory pattern

Suggested structure:
// notification.factory.ts
export class NotificationFactory {
  createNotification(type: CaseNotificationType): BaseNotificationHandler {
    switch (type) {
      case CaseNotificationType.APPEAL:
        return new AppealNotificationHandler();
      case CaseNotificationType.RULING:
        return new RulingNotificationHandler();
      // ...
    }
  }
}

// handlers/appeal.notification.handler.ts
export class AppealNotificationHandler extends BaseNotificationHandler {
  // Appeal-specific notification logic
}

// handlers/ruling.notification.handler.ts
export class RulingNotificationHandler extends BaseNotificationHandler {
  // Ruling-specific notification logic
}
apps/judicial-system/backend/src/app/modules/notification/services/defendantNotification/defendantNotification.service.ts (2)
182-217: Consider refactoring to reduce code duplication

The methods sendIndictmentSentToPrisonAdminNotification and sendIndictmentWithdrawnFromPrisonAdminNotification have similar structures and duplicate code for formatting messages and preparing recipients. Consider extracting the common logic into a helper method to improve maintainability.

Apply this diff to refactor the code:
+private preparePrisonAdminNotification(
+  theCase: Case,
+  subjectTemplate: string,
+  bodyTemplate: string,
+  notificationType: DefendantNotificationType,
+): Promise<DeliverResponse> {
+  const formattedSubject = this.formatMessage(subjectTemplate, {
+    courtCaseNumber: theCase.courtCaseNumber,
+  })
+
+  const formattedBody = this.formatMessage(bodyTemplate, {
+    courtCaseNumber: theCase.courtCaseNumber,
+    linkStart: `<a href="${this.config.clientUrl}${ROUTE_HANDLER_ROUTE}/${theCase.id}">`,
+    linkEnd: '</a>',
+  })
+
+  const to = this.config.email.prisonAdminIndictmentEmails
+    .split(',')
+    .map((email) => email.trim())
+    .map((email) => ({
+      name: 'Fangelsismálastofnun',
+      email,
+    }))
+
+  return this.sendEmails(
+    theCase,
+    notificationType,
+    formattedSubject,
+    formattedBody,
+    to,
+  )
+}
Then, modify the existing methods to use this helper:
-private sendIndictmentSentToPrisonAdminNotification(theCase: Case) {
-  const formattedSubject = this.formatMessage(
-    strings.indictmentSentToPrisonAdminSubject,
-    {
-      courtCaseNumber: theCase.courtCaseNumber,
-    },
-  )
-  // ... rest of the method
-}
+private sendIndictmentSentToPrisonAdminNotification(theCase: Case) {
+  return this.preparePrisonAdminNotification(
+    theCase,
+    strings.indictmentSentToPrisonAdminSubject,
+    strings.indictmentSentToPrisonAdminBody,
+    DefendantNotificationType.INDICTMENT_SENT_TO_PRISON_ADMIN,
+  )
+}
-private sendIndictmentWithdrawnFromPrisonAdminNotification(theCase: Case) {
-  const formattedSubject = this.formatMessage(
-    strings.indictmentWithdrawnFromPrisonAdminSubject,
-    {
-      courtCaseNumber: theCase.courtCaseNumber,
-    },
-  )
-  // ... rest of the method
-}
+private sendIndictmentWithdrawnFromPrisonAdminNotification(theCase: Case) {
+  return this.preparePrisonAdminNotification(
+    theCase,
+    strings.indictmentWithdrawnFromPrisonAdminSubject,
+    strings.indictmentWithdrawnFromPrisonAdminBody,
+    DefendantNotificationType.INDICTMENT_WITHDRAWN_FROM_PRISON_ADMIN,
+  )
+}
205-206: Externalize hardcoded recipient name for better maintainability

The recipient name 'Fangelsismálastofnun' is hardcoded in both methods. Consider externalizing this string into a configuration or localization file to facilitate easier updates and localization in the future.

Also applies to: 242-243

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 78bdd5b and 207d74f.

📒 Files selected for processing (22)

apps/judicial-system/backend/infra/judicial-system-backend.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/defendant/defendant.service.ts (3 hunks)
apps/judicial-system/backend/src/app/modules/defendant/test/defendantController/update.spec.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/internalNotification.controller.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/notification.config.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/notification.module.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/services/caseNotification/caseNotification.service.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/services/civilClaimantNotification/civilClaimantNotification.service.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/services/defendantNotification/defendantNotification.service.ts (3 hunks)
apps/judicial-system/backend/src/app/modules/notification/services/defendantNotification/defendantNotification.strings.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/services/institutionNotification/institutionNotification.service.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/services/subpoenaNotification/subpoenaNotification.service.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/test/createTestingNotificationModule.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/test/internalNotificationController/defendantNotification/sendIndictmentSentToPrisonAdminNotification.spec.ts (1 hunks)
apps/judicial-system/backend/src/app/modules/notification/test/internalNotificationController/defendantNotification/sendIndictmentWithdrawnFromPrisonAdminNotifications.spec.ts (1 hunks)
charts/judicial-system/values.dev.yaml (1 hunks)
charts/judicial-system/values.prod.yaml (1 hunks)
charts/judicial-system/values.staging.yaml (1 hunks)
charts/services/judicial-system-backend/values.dev.yaml (1 hunks)
charts/services/judicial-system-backend/values.prod.yaml (1 hunks)
charts/services/judicial-system-backend/values.staging.yaml (1 hunks)
libs/judicial-system/types/src/lib/notification.ts (2 hunks)

✅ Files skipped from review due to trivial changes (2)

apps/judicial-system/backend/src/app/modules/notification/services/civilClaimantNotification/civilClaimantNotification.service.ts
apps/judicial-system/backend/src/app/modules/notification/services/subpoenaNotification/subpoenaNotification.service.ts

🧰 Additional context used

📓 Path-based instructions (14)

apps/judicial-system/backend/infra/judicial-system-backend.ts (1)