Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(j-s): Civil Demands #16010

Merged
merged 6 commits into from
Sep 16, 2024
Merged

feat(j-s): Civil Demands #16010

merged 6 commits into from
Sep 16, 2024

Conversation

gudjong
Copy link
Member

@gudjong gudjong commented Sep 13, 2024

Civil Demands

Bótakrafa - bæta við einkaréttarkröfureit á ákæruskjáinn

What

  • Adds a new field for civil demands in the indictment in traffic violation cases.
  • In this implementation, the demands are always required, but will later be conditionally required based on the presence of civil claimants.
  • This PR also rewrites the handling of case strings that are store in a separate table.

Why

  • Necessary for indictment MVP.

Screenshots / Gifs

image

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 a new optional field, civilDemands, to various case-related inputs and models, enhancing case management capabilities.
    • Added interceptors for improved data processing in case-related endpoints, ensuring consistent handling of case data.
    • Enhanced indictment document generation to include civil demands information.
    • Added a localized heading for civil demands in the PDF output for better clarity.
  • Bug Fixes

    • Streamlined logic for handling court dates and case file access based on user roles.
  • Documentation

    • Added new strings for civil demands in the user interface to improve clarity during the indictment process.
  • Refactor

    • Replaced ExplanatoryComment with CaseString across multiple modules, improving data handling and structure.

@gudjong gudjong requested a review from a team as a code owner September 13, 2024 17:00
Copy link
Contributor

coderabbitai bot commented Sep 13, 2024

Walkthrough

The changes in this pull request involve a significant restructuring of the case management system within the judicial system API. Key modifications include the introduction of the CaseString model, which replaces the previous ExplanatoryComment model, and the addition of a new optional field civilDemands. Various interceptors and controllers have been updated to accommodate these changes, enhancing the data handling and processing for case-related information.

Changes

File Path Change Summary
apps/judicial-system/backend/src/app/modules/case/case.service.ts Introduced CaseString model, updated UpdateCase interface to include civilDemands, and modified handling of case strings.
apps/judicial-system/backend/src/app/modules/case/interceptors/case.interceptor.ts Added CaseInterceptor and CasesInterceptor for transforming case data.
apps/judicial-system/backend/src/app/modules/case/interceptors/caseFile.interceptor.ts Refactored access control logic for case files.
apps/judicial-system/backend/src/app/modules/case/interceptors/caseList.interceptor.ts Updated logic for deriving postponedIndefinitelyExplanation using CaseString.
apps/judicial-system/backend/src/app/modules/case/interceptors/caseOriginalAncestor.interceptor.ts Simplified method signature and improved type safety.
apps/judicial-system/backend/src/app/modules/case/interceptors/completedAppealAccessed.interceptor.ts Refactored user role checks into utility functions.
apps/judicial-system/backend/src/app/modules/case/internalCase.controller.ts Added interceptors and modified route for fetching indictment case by ID.
apps/judicial-system/backend/src/app/modules/case/internalCase.service.ts Replaced ExplanatoryComment with CaseString, updated data handling logic.
apps/judicial-system/backend/src/app/modules/case/models/caseString.model.ts Refactored ExplanatoryComment class into CaseString, updated properties and methods.
apps/judicial-system/backend/src/app/formatters/indictmentPdf.ts Enhanced PDF generation to include civil demands using the CaseString model.
apps/judicial-system/backend/src/app/messages/pdfIndictment.ts Added new message definition for civilDemandsHeading to enhance localization for PDF outputs.
apps/judicial-system/backend/src/app/modules/case/dto/updateCase.input.ts Added optional field civilDemands to UpdateCaseInput class.
apps/judicial-system/backend/src/app/modules/case/models/case.model.ts Added optional property civilDemands to Case class; renamed explanatoryComments to caseStrings.
apps/judicial-system/backend/src/app/modules/case/interceptors/caseFile.interceptor.ts Simplified logic for determining user access to case files based on roles.

Possibly related PRs


Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between f9856d1 and 2041177.

Files selected for processing (1)
  • apps/judicial-system/backend/src/app/modules/case/case.service.ts (8 hunks)
Files skipped from review due to trivial changes (1)
  • apps/judicial-system/backend/src/app/modules/case/case.service.ts

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?

Share
Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    -- I pushed a fix in commit <commit_id>, please review it.
    -- Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    -- @coderabbitai generate unit testing code for this file.
    -- @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    -- @coderabbitai generate interesting stats about this repository and render them as a table.
    -- @coderabbitai read src/utils.ts and generate unit testing code.
    -- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    -- @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Outside diff range and nitpick comments (1)
apps/judicial-system/backend/src/app/modules/case/interceptors/completedAppealAccessed.interceptor.ts (1)

25-25: Consider using a more specific return type for improved type safety and code readability.

The change in the return type of the intercept method from Observable<Case> to Observable provides flexibility for future changes in the data structure being returned. However, the lack of a specific return type may reduce type safety and make the code less self-documenting.

If possible, consider using a more specific return type that accurately represents the data structure being returned. This will improve type safety and make the code more readable and maintainable.

Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between dddefda and 7ad5f8d.

Files selected for processing (34)
  • apps/judicial-system/api/src/app/modules/backend/backend.service.ts (1 hunks)
  • apps/judicial-system/api/src/app/modules/case/dto/updateCase.input.ts (1 hunks)
  • apps/judicial-system/api/src/app/modules/case/models/case.model.ts (1 hunks)
  • apps/judicial-system/backend/migrations/20240909194458-rename-explanatory-comment.js (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/case.controller.ts (9 hunks)
  • apps/judicial-system/backend/src/app/modules/case/case.module.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/case/case.service.ts (8 hunks)
  • apps/judicial-system/backend/src/app/modules/case/dto/updateCase.dto.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/guards/rolesRules.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/interceptors/case.interceptor.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/interceptors/caseFile.interceptor.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/interceptors/caseList.interceptor.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/case/interceptors/caseOriginalAncestor.interceptor.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/interceptors/completedAppealAccessed.interceptor.ts (1 hunks)
  • apps/judicial-system/backend/src/app/modules/case/internalCase.controller.ts (5 hunks)
  • apps/judicial-system/backend/src/app/modules/case/internalCase.service.ts (7 hunks)
  • apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.controller.ts (4 hunks)
  • apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (4 hunks)
  • apps/judicial-system/backend/src/app/modules/case/models/case.model.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/case/models/caseString.model.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/case/test/caseController/update.spec.ts (6 hunks)
  • apps/judicial-system/backend/src/app/modules/case/test/createTestingCaseModule.ts (4 hunks)
  • apps/judicial-system/backend/src/app/modules/case/test/internalCaseController/archive.spec.ts (11 hunks)
  • apps/judicial-system/backend/src/app/modules/event/event.service.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/file/guards/caseFileCategory.ts (3 hunks)
  • apps/judicial-system/backend/src/app/modules/file/guards/limitedAccessViewCaseFile.guard.ts (2 hunks)
  • apps/judicial-system/backend/src/app/modules/file/index.ts (1 hunks)
  • apps/judicial-system/digital-mailbox-api/src/app/modules/cases/case.service.ts (1 hunks)
  • apps/judicial-system/web/src/components/FormProvider/case.graphql (1 hunks)
  • apps/judicial-system/web/src/routes/Prosecutor/Indictments/Indictment/Indictment.strings.ts (1 hunks)
  • apps/judicial-system/web/src/routes/Prosecutor/Indictments/Indictment/Indictment.tsx (3 hunks)
  • apps/judicial-system/web/src/utils/validate.ts (1 hunks)
  • libs/judicial-system/types/src/index.ts (1 hunks)
  • libs/judicial-system/types/src/lib/caseString.ts (1 hunks)
Additional context used
Path-based instructions (34)
libs/judicial-system/types/src/lib/caseString.ts (1)

Pattern libs/**/*: "Confirm that the code adheres to the following:

  • Reusability of components and hooks across different NextJS apps.
  • TypeScript usage for defining props and exporting types.
  • Effective tree-shaking and bundling practices."
apps/judicial-system/backend/src/app/modules/file/index.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/interceptors/caseOriginalAncestor.interceptor.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/interceptors/caseFile.interceptor.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/interceptors/case.interceptor.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/interceptors/completedAppealAccessed.interceptor.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/file/guards/limitedAccessViewCaseFile.guard.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/migrations/20240909194458-rename-explanatory-comment.js (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/models/caseString.model.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/case.module.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/file/guards/caseFileCategory.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
libs/judicial-system/types/src/index.ts (1)

Pattern libs/**/*: "Confirm that the code adheres to the following:

  • Reusability of components and hooks across different NextJS apps.
  • TypeScript usage for defining props and exporting types.
  • Effective tree-shaking and bundling practices."
apps/judicial-system/backend/src/app/modules/case/interceptors/caseList.interceptor.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Indictment/Indictment.strings.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/web/src/components/FormProvider/case.graphql (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/event/event.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/test/createTestingCaseModule.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/digital-mailbox-api/src/app/modules/cases/case.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/guards/rolesRules.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/api/src/app/modules/backend/backend.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/api/src/app/modules/case/dto/updateCase.input.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.controller.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/dto/updateCase.dto.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/api/src/app/modules/case/models/case.model.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/test/internalCaseController/archive.spec.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/web/src/utils/validate.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Indictment/Indictment.tsx (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/internalCase.controller.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/test/caseController/update.spec.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/case.controller.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/models/case.model.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/internalCase.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/backend/src/app/modules/case/case.service.ts (1)

Pattern apps/**/*: "Confirm that the code adheres to the following:

  • NextJS best practices, including file structure, API routes, and static generation methods.
  • Efficient state management and server-side rendering techniques.
  • Optimal use of TypeScript for component and utility type safety."
Biome
apps/judicial-system/backend/migrations/20240909194458-rename-explanatory-comment.js

[error] 1-1: Redundant use strict directive.

The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.

(lint/suspicious/noRedundantUseStrict)

Additional comments not posted (87)
libs/judicial-system/types/src/lib/caseString.ts (2)

1-3: LGTM!

The renaming of the enum from CommentType to StringType and the addition of the CIVIL_DEMANDS member are appropriate changes that expand the functionality of the enum while maintaining backward compatibility.


3-3: Verify the usage of the new enum member CIVIL_DEMANDS across the codebase.

Ensure that the new enum member is being used correctly in all relevant places across the codebase, such as in case creation, update logic, and display components.

Run the following script to verify the enum member usage:

apps/judicial-system/backend/src/app/modules/file/index.ts (1)

3-6: LGTM!

The addition of the canLimitedAcccessUserViewCaseFile export is a clear and straightforward change that aligns with the file's purpose and structure. The function name is descriptive and suggests it handles access control for limited access users viewing case files, which is a reasonable addition to this module.

The existing defenderCaseFileCategoriesForRestrictionAndInvestigationCases export remains unchanged, maintaining backwards compatibility.

Overall, this is a clean and focused change that enhances the module's functionality without introducing any issues.

apps/judicial-system/backend/src/app/modules/case/interceptors/caseOriginalAncestor.interceptor.ts (3)

10-10: LGTM!

The import statement for the Case model is correct and necessary for using the Case type in this file.


16-16: LGTM!

Removing the return type declaration Promise<Observable<unknown>> from the intercept method signature streamlines the code without affecting its functionality. The method is still expected to return a promise that resolves to an observable.


19-19: LGTM!

Explicitly typing theCase as Case enhances type safety and clarity regarding the expected structure of the case object retrieved from the request. This change improves the code's readability and maintainability without altering the underlying logic.

apps/judicial-system/backend/src/app/modules/case/interceptors/caseFile.interceptor.ts (3)

10-12: LGTM!

The import statements for the required types and function are correctly added.


16-32: Great refactor!

The changes to the intercept method significantly improve the clarity and maintainability of the access control logic. By introducing the canLimitedAcccessUserViewCaseFile function, the code is more readable and easier to understand.

The adjustments to the return value also promote immutability, which aligns with best practices in functional programming.

Overall, the refactor adheres to NextJS best practices and efficiently uses TypeScript for type safety.


16-16: Return type change is acceptable.

The return type of the intercept method has been changed to the inferred return type. This change is acceptable as the method is still returning an observable.

The inferred return type provides flexibility and reduces the need for explicit type annotations.

apps/judicial-system/backend/src/app/modules/case/interceptors/case.interceptor.ts (3)

22-27: LGTM!

The CaseInterceptor correctly implements the NestInterceptor interface and uses the transformCase function to augment the case object with additional properties. The use of RxJS map operator to transform the response data is a good practice.


29-38: LGTM!

The CasesInterceptor correctly implements the NestInterceptor interface and uses the transformCase function to augment each case object in the array with additional properties. The use of RxJS map operator to transform the response data is a good practice.


13-20: LGTM!

The transformCase function correctly transforms the case object by adding postponedIndefinitelyExplanation and civilDemands properties. The use of the CaseString model to derive the values for these properties is a good practice.

apps/judicial-system/backend/src/app/modules/case/interceptors/completedAppealAccessed.interceptor.ts (1)

33-35: Excellent refactoring of user role checks!

The refactoring of user role checks into dedicated utility functions (isProsecutionUser, isDefenceUser, and isPrisonStaffUser) greatly improves code readability and maintainability. This change aligns with best practices for code organization and separation of concerns.

The new utility functions can potentially encapsulate more complex logic in the future without cluttering the interceptor's main flow.

apps/judicial-system/backend/src/app/modules/file/guards/limitedAccessViewCaseFile.guard.ts (1)

39-44: LGTM!

The refactoring of the access control logic into the canLimitedAcccessUserViewCaseFile function improves code readability and maintainability. The guard's functionality remains preserved as the new function is expected to handle the access control logic correctly.

apps/judicial-system/backend/migrations/20240909194458-rename-explanatory-comment.js (1)

3-50: LGTM!

The migration script follows best practices and improves the naming conventions in the database schema. The use of transactions ensures data integrity during the renaming process, and the down function allows reverting the changes if needed.

apps/judicial-system/backend/src/app/modules/case/models/caseString.model.ts (5)

13-13: LGTM!

The import statement for StringType enum is correctly formatted and follows the best practices for importing types from a shared library.


18-21: LGTM!

The CaseString model class definition and the @Table decorator are correctly formatted and follow the best practices for defining Sequelize models. The table name follows the naming convention for database tables, and enabling timestamps is a good practice for tracking the creation and modification dates of the records.


22-32: LGTM!

The static methods postponedIndefinitelyExplanation and civilDemands are correctly formatted and follow the best practices for defining static methods in a model class. The methods efficiently retrieve the desired case string using the find method and the optional chaining operator to safely access the value property.


55-58: LGTM!

The stringType property is correctly defined using the @Column decorator with the DataType.ENUM and the values option set to Object.values(StringType). This ensures that the property can only have values defined in the StringType enum. The @ApiProperty decorator is correctly used to specify the enum type for the Swagger documentation, improving the API documentation quality.


65-67: LGTM!

The value property is correctly defined using the @Column decorator with the DataType.TEXT, allowing for storing longer text values, which is appropriate for case strings that may contain detailed information. The @ApiPropertyOptional decorator is correctly used to specify the property type for the Swagger documentation, improving the API documentation quality.

apps/judicial-system/backend/src/app/modules/case/case.module.ts (2)

22-22: LGTM!

The import statement for the new CaseString model is correctly placed and follows the existing code structure.


46-46: Looks good!

The modifications to the Sequelize module's feature declarations correctly reflect the changes in the case management data structure. The removal of ExplanatoryComment and addition of CaseString are consistent with the updated model imports.

apps/judicial-system/backend/src/app/modules/file/guards/caseFileCategory.ts (3)

Line range hint 25-34: LGTM!

The change from export const to const for defenderCaseFileCategoriesForIndictmentCases is a good refactor. It aligns with the best practice of only exporting entities that are intended to be used outside the module.


36-39: LGTM!

Similar to the previous change, modifying prisonAdminCaseFileCategories from export const to const is a good refactor. It ensures that the constant is only used internally within the module, following best practices.


41-79: Great work on the new canLimitedAcccessUserViewCaseFile function!

The function introduces a robust and well-structured access control mechanism for determining user access to case files based on their roles and case-specific conditions. Here are some key strengths of the implementation:

  1. Clear separation of conditions for different user roles (defense users and prison admin users), making the logic easy to follow and maintain.
  2. Use of type-safe parameters and return values, ensuring that the function is used correctly and preventing potential runtime errors.
  3. Adherence to the Single Responsibility Principle, with the function focused solely on determining user access to case files.

The code segment is well-written and enhances the overall access control functionality of the judicial system. Great job!

libs/judicial-system/types/src/index.ts (1)

15-15: Verify the usage of CommentType and StringType in the codebase.

The changes involve removing the export of CommentType and adding the export of StringType. This suggests that CommentType is no longer used in the codebase and StringType is being used instead.

Run the following script to verify the usage of CommentType and StringType:

apps/judicial-system/backend/src/app/modules/case/interceptors/caseList.interceptor.ts (2)

13-13: LGTM!

The import statement for the CaseString model is correct and follows the proper syntax. The relative import path is accurate based on the file structure.


60-60: Verify the logic of the postponedIndefinitelyExplanation method.

The code change to derive the postponedIndefinitelyExplanation using the CaseString.postponedIndefinitelyExplanation method with theCase.caseStrings as an argument looks good. The syntax is correct and consistent with the imported CaseString model.

However, please verify that the logic within the postponedIndefinitelyExplanation method in the CaseString model correctly constructs the explanation based on the caseStrings data, as this might have changed from the previous implementation using explanatoryComments.

apps/judicial-system/web/src/routes/Prosecutor/Indictments/Indictment/Indictment.strings.ts (3)

97-102: LGTM!

The string definition for civilDemandsTitle looks good. The ID, default message, and description are appropriate and provide clear context.


103-108: LGTM!

The string definition for civilDemandsLabel looks good. The ID, default message, and description are appropriate and provide clear context.


109-114: LGTM!

The string definition for civilDemandsPlaceholder looks good. The ID, default message, and description are appropriate and provide clear context.

apps/judicial-system/web/src/components/FormProvider/case.graphql (1)

311-311: LGTM!

The addition of the civilDemands field to the Case query is a valid change. It follows the naming convention and is placed at the correct location within the query.

The field will allow retrieving information related to civil demands for a case, enhancing the data retrieval capabilities of the query.

apps/judicial-system/backend/src/app/modules/event/event.service.ts (2)

21-21: LGTM!

The import statement for the CaseString model is correct.


124-128: The code changes look good!

The court date or arraignment date is now always formatted using the formatDate function, defaulting to "er ekki skráð" (is not recorded) if no date is available. This simplifies the logic by removing the conditional dependency on explanatory comments.

Note that this change may alter the output in cases where the court date was previously marked as postponed indefinitely. Please ensure that this behavior aligns with the desired functionality.

apps/judicial-system/backend/src/app/modules/case/test/createTestingCaseModule.ts (3)

36-36: LGTM!

The import change from ExplanatoryComment to CaseString is consistent with the overall refactoring mentioned in the PR summary.


Line range hint 117-122: LGTM!

The provider configuration change from ExplanatoryComment to CaseString aligns with the overall refactoring mentioned in the PR summary.


167-168: LGTM!

The change in the retrieval of the model instance from ExplanatoryComment to CaseString is consistent with the overall refactoring mentioned in the PR summary.

apps/judicial-system/digital-mailbox-api/src/app/modules/cases/case.service.ts (1)

193-193: LGTM! Verify backend API compatibility.

The change in the fetch URL from /api/internal/cases/indictment/${id} to /api/internal/case/indictment/${id} looks good and aligns with the mentioned API restructuring.

However, please ensure that the backend API has been updated to handle this new URL structure. You can verify this by running the following script:

Make sure to replace <replace-with-a-valid-case-id>, <replace-with-a-valid-national-id>, and <replace-with-the-actual-secret-token> with appropriate values before running the script.

apps/judicial-system/backend/src/app/modules/case/guards/rolesRules.ts (2)

55-55: LGTM!

The addition of the civilDemands field to the prosecutorFields array is consistent with the PR objective and follows the existing conventions. The change is well-contained and does not introduce any syntax or formatting issues.


55-55: Verify the usage of the civilDemands field.

To ensure the civilDemands field is being properly utilized, please verify its usage in other relevant parts of the codebase, such as in the corresponding DTOs, models, and services.

Verification successful

To gather more comprehensive information about the usage of the civilDemands field, I'll generate new shell scripts to perform a broader search.


The civilDemands field is properly utilized across the judicial system application.

The verification process has confirmed that the civilDemands field is extensively used in various components of the judicial system application, including:

  • Case models in both API and backend
  • Update DTOs and inputs for case modifications
  • Validation logic for application steps
  • UI string constants for frontend display
  • Case update processes and storage as a CaseString type
  • Access control rules and roles

This widespread usage indicates that the field is an integral part of the system and is being properly utilized as intended.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the `civilDemands` field in the codebase.

# Test 1: Search for the field in DTOs. Expect: Usage in relevant DTOs.
rg --type typescript -A 5 $'civilDemands' $(fd -e dto.ts)

# Test 2: Search for the field in models. Expect: Usage in relevant models.
rg --type typescript -A 5 $'civilDemands' $(fd -e model.ts)

# Test 3: Search for the field in services. Expect: Usage in relevant services.
rg --type typescript -A 5 $'civilDemands' $(fd -e service.ts)

Length of output: 120964


Script:

#!/bin/bash
# Search for 'civilDemands' in all TypeScript and JavaScript files
echo "Searching for 'civilDemands' in all .ts and .js files:"
rg --type-add 'script:*.{ts,js}' -t script 'civilDemands' -C 3

echo "\nSearching for related terms:"
rg --type-add 'script:*.{ts,js}' -t script 'civil[D|d]emands?' -C 3

echo "\nSearching for potential camelCase variations:"
rg --type-add 'script:*.{ts,js}' -t script 'civil[A-Z][a-zA-Z]*' -C 3

Length of output: 31258

apps/judicial-system/api/src/app/modules/backend/backend.service.ts (1)

9-9: LGTM! The changes simplify the case data transformation.

The removal of the explanatoryComments property and related logic, including the postponedIndefinitelyExplanation extraction, streamlines the caseTransformer method by reducing the complexity of the constructed case object.

This change suggests that:

  1. The handling of postponed cases may now be less detailed, or this information is no longer necessary for the current functionality.
  2. The overall data structure returned by the transformer is simplified.

Ensure that these changes align with the current requirements and don't adversely impact any dependent functionality.

Also applies to: 115-125

apps/judicial-system/api/src/app/modules/case/dto/updateCase.input.ts (1)

509-513: LGTM!

The new optional field civilDemands is a valid addition to the UpdateCaseInput class. The field is correctly decorated with @Allow(), @IsOptional(), and @Field() decorators to ensure proper validation, GraphQL schema exposure, and optional behavior.

apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.controller.ts (3)

85-89: LGTM!

The addition of the CaseInterceptor to the @UseInterceptors decorator for the getById method follows NestJS best practices. The interceptor is likely to enhance the processing of requests related to limited access cases.


123-123: Looks good!

The addition of the CaseInterceptor to the @UseInterceptors decorator for the update method follows NestJS best practices and is consistent with the changes made to the getById method.


152-152: LGTM!

The addition of the CaseInterceptor to the @UseInterceptors decorator for the transition method follows NestJS best practices and is consistent with the changes made to the other methods in this controller.

apps/judicial-system/backend/src/app/modules/case/dto/updateCase.dto.ts (1)

516-520: LGTM!

The new optional civilDemands property is implemented correctly with proper validation and documentation decorators. This aligns well with the PR objective to introduce a new field for civil demands within the indictment process.

apps/judicial-system/backend/src/app/modules/case/limitedAccessCase.service.ts (4)

27-27: LGTM!

The change from CommentType to StringType aligns with the overall shift towards a more generalized string management approach in the codebase.


119-119: Looks good!

Replacing commentTypes with stringTypes is in line with the transition from CommentType to StringType. This change maintains consistency throughout the codebase.


217-217: LGTM!

Filtering CaseString records based on the stringType field aligns perfectly with the transition to StringType and the usage of the stringTypes array. This ensures that only relevant records are included.


214-215: Verify the impact of replacing ExplanatoryComment with CaseString.

The change from ExplanatoryComment to CaseString suggests a significant update to the data handling logic within the service, moving towards a more generalized string management approach.

Please ensure that this change does not introduce any unintended side effects or break existing functionality related to case data processing and querying.

Run the following script to verify the usage of CaseString model:

Verification successful

Replacement of ExplanatoryComment with CaseString verified

The change from ExplanatoryComment to CaseString has been implemented consistently across the codebase. No references to ExplanatoryComment were found, while CaseString is now widely used in various modules, including models, services, and tests. This indicates a thorough refactoring with no apparent side effects or inconsistencies.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of `CaseString` model in the codebase.

# Test 1: Search for the model usage in TypeScript files. 
# Expect: Only valid usage of the `CaseString` model.
rg --type ts $'CaseString' -A 5

# Test 2: Search for the previous model usage in TypeScript files.
# Expect: No usage of the `ExplanatoryComment` model. 
rg --type ts $'ExplanatoryComment' -A 5

Length of output: 32607

apps/judicial-system/api/src/app/modules/case/models/case.model.ts (1)

456-458: LGTM!

The new optional civilDemands property is a valuable addition to the Case model. It allows capturing additional information relevant to civil cases, thereby improving the functionality and flexibility of the case management system.

The property is appropriately typed as a nullable string using the @Field decorator from @nestjs/graphql, and the code change adheres to the existing code style and conventions used in the file.

apps/judicial-system/backend/src/app/modules/case/test/internalCaseController/archive.spec.ts (5)

23-23: LGTM!

The import statement for the CaseString model is correct.


39-39: LGTM!

The variable declaration for mockCaseStringModel is correct.


52-52: LGTM!

The assignments and test data updates for the CaseString model are correct.

Also applies to: 62-62, 93-94, 171-173


243-245: LGTM!

The test data update for the caseStrings in the expected archived case data is correct.


254-255: LGTM!

The mock setup and expectations for the CaseString model's update method are correct.

Also applies to: 276-276, 286-286, 334-340

apps/judicial-system/web/src/utils/validate.ts (1)

278-278: LGTM!

The updated validation logic correctly requires both demands and civilDemands to be present for the traffic violation step to be considered valid. This aligns with the PR objective of making civil demands required for the indictment MVP.

apps/judicial-system/web/src/routes/Prosecutor/Indictments/Indictment/Indictment.tsx (3)

100-101: LGTM!

The new state variable for handling civil demands errors is introduced correctly, following the existing naming convention and initialization pattern.


430-430: Good use of the nullish coalescing operator.

Using ?? to provide a default empty string when workingCase.demands is undefined is a good practice. It ensures that the component behaves predictably and prevents uncontrolled behavior.


461-498: New civil demands section looks good!

The new section for handling civil demands is implemented correctly:

  • It follows the existing structure and styling patterns.
  • The input field is properly integrated with the civilDemandsErrorMessage state for validation.
  • It utilizes the removeTabsValidateAndSet and validateAndSendToServer utility functions for consistent validation behavior.

Great job!

apps/judicial-system/backend/src/app/modules/case/internalCase.controller.ts (6)

55-55: LGTM!

The addition of the CaseInterceptor to the create method is a good practice for enhancing the functionality of the case creation endpoint.


85-85: LGTM!

The addition of the CasesInterceptor to the getIndictmentCases method is a good practice for enhancing the functionality of the endpoint that retrieves all indictment cases.


96-96: LGTM!

The modification of the route from cases/indictment/:caseId to case/indictment/:caseId improves the clarity and consistency of the API endpoint paths.


Line range hint 113-133:


Line range hint 135-155:


101-105: Verify the impact of the return type change.

The return type of the getIndictmentCase method has been changed from Promise<Case | null> to Promise<Case>, suggesting that the method will no longer return null under certain conditions.

Please ensure that this change in behavior is intended and does not introduce any breaking changes or unexpected behavior in the codebase.

Run the following script to verify the usage of the getIndictmentCase method:

Verification successful

Return type change for getIndictmentCase appears consistent and intentional

The verification process confirms that the return type change from Promise<Case | null> to Promise<Case> for the getIndictmentCase method is consistent across the codebase. No null checks were found for this method's return value, suggesting that the change is intentional and doesn't introduce unexpected behavior.

Key observations:

  • The method declaration in internalCase.controller.ts shows the updated return type Promise<Case>.
  • The implementation in internalCase.service.ts doesn't show any obvious null handling.
  • No occurrences of null checks on the return value of getIndictmentCase were found in the codebase.

Based on these findings, it appears that the change in behavior is intended and doesn't introduce breaking changes or unexpected behavior in the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of the `getIndictmentCase` method and its return value handling.

# Test: Search for the method usage. Expect: No occurrences of null checks on the return value.
rg --type typescript -A 5 $'getIndictmentCase'

Length of output: 80


Script:

#!/bin/bash
# Search for getIndictmentCase method declaration and usage
rg 'getIndictmentCase' -A 5

# Search for the method declaration using ast-grep
ast-grep --lang typescript --pattern 'getIndictmentCase($$$) { $$$ }'

# Search for potential null checks on the return value
rg 'getIndictmentCase.*\s*(===|!==|==|!=)\s*null' -A 5
rg 'getIndictmentCase.*\s*\?\?' -A 5

Length of output: 8449

apps/judicial-system/backend/src/app/modules/case/test/caseController/update.spec.ts (5)

18-18: LGTM!

The addition of the StringType import is necessary to support the usage of the new CaseString model and the transition away from ExplanatoryComment.


31-31: LGTM!

The addition of the CaseString model import is necessary to support the transition from the ExplanatoryComment model to CaseString, as mentioned in the high-level summary.


76-76: LGTM!

The renaming of the variable from mockExplanatoryCommentModel to mockCaseStringModel is appropriate to align with the transition from the ExplanatoryComment model to CaseString, as mentioned in the high-level summary.


87-87: LGTM!

The destructuring of caseStringModel from the createTestingCaseModule function is appropriate and aligns with the previous changes related to the transition to the CaseString model.


916-940: LGTM!

The addition of the test case for updating civil demands is excellent! It aligns perfectly with the PR objective of introducing the new civilDemands field and ensures that the field is properly handled when updated.

The test case verifies that a new entry is created in the CaseString model with the correct stringType and value, following the existing patterns in the test file.

apps/judicial-system/backend/src/app/modules/case/case.controller.ts (8)

Line range hint 147-159: LGTM!

The create method correctly uses the CaseInterceptor to enhance the processing of requests for creating cases. It follows best practices by using DTOs for request body validation and returning the created case.


Line range hint 175-283: LGTM!

The update method correctly uses the CaseInterceptor to enhance the processing of requests for updating cases. It performs necessary validations for the assigned users based on their roles and institutions. The method also handles updates to various fields with appropriate checks and transformations.


Line range hint 293-443: LGTM!

The transition method correctly uses the CaseInterceptor to enhance the processing of requests for transitioning cases. It handles various case transitions with appropriate updates and checks based on the case type and state. The method also posts an event after the case transition, which is a good practice for event-driven architectures.


448-456: LGTM!

The getAll method correctly uses the CaseListInterceptor to enhance the processing of requests for retrieving all cases. It returns a promise of an array of cases, which is a good practice for asynchronous operations.


Line range hint 473-480: LGTM!

The getById method correctly uses the CompletedAppealAccessedInterceptor and CaseInterceptor to enhance the processing of requests for retrieving a case by ID. It returns the case directly, as it is already available through the @CurrentCase() decorator.


Line range hint 488-508: LGTM!

The getConnectedCases method correctly uses the CasesInterceptor to enhance the processing of requests for retrieving connected cases. It handles the case when there are no defendants and returns an empty array. The method also uses Promise.all to retrieve connected cases for each defendant in parallel, which is an efficient approach.


Line range hint 883-904: LGTM!

The extend method correctly uses the CaseInterceptor to enhance the processing of requests for extending cases. It checks if the case already has a child case and returns it if it exists, avoiding unnecessary cloning. The method also posts an event after extending the case, which is a good practice for event-driven architectures.


Line range hint 913-927: LGTM!

The createCourtCase method correctly uses the CaseInterceptor to enhance the processing of requests for creating court cases. It returns the created court case, which is a good practice for providing the updated case information to the client.

apps/judicial-system/backend/src/app/modules/case/models/case.model.ts (1)

904-908: Refactoring to CaseString model looks good!

The change from explanatoryComments associated with ExplanatoryComment model to caseStrings associated with CaseString model aligns with the provided summary. This refactoring likely provides a more flexible way to represent case-related textual data.

The TypeScript types and Swagger annotations have been updated correctly.

apps/judicial-system/backend/src/app/modules/case/internalCase.service.ts (6)

67-67: LGTM!

The import statement for the CaseString model is correct.


122-122: LGTM!

The caseStringEncryptionProperties constant is correctly defined to specify the encryption properties for the CaseString model.


149-150: LGTM!

The CaseString model is correctly injected into the InternalCaseService constructor and assigned to the caseStringModel property.


394-400: LGTM!

The CaseString model is correctly included in the query to find a case for archiving, and the caseStrings are ordered by the created field in ascending order.


460-472: LGTM!

The caseStrings are correctly archived by:

  1. Collecting the encryption properties of the caseStrings.
  2. Updating the caseStrings with the cleared properties.
  3. Adding the archived caseStrings to the caseStringsArchive array.

The code changes are consistent with the archiving process for other entities.


1231-1231: Verify the method signature change in the codebase.

The method signature change is correct. However, ensure that all method calls to getIndictmentCase have been updated to handle the new return type.

Run the following script to verify the method usage:

Verification successful

Method signature change verified and correctly implemented

The getIndictmentCase method signature change has been properly implemented and used throughout the codebase. No issues were found with its usage, and the lack of null checks is consistent with the new return type of Promise<Case>. The change appears to be safe and correctly handled in the codebase.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify all method calls to `getIndictmentCase` handle the new return type.

# Test: Search for the method usage. Expect: No `null` checks on the returned value.
rg --type typescript -A 5 $'getIndictmentCase'

Length of output: 80


Script:

#!/bin/bash
# Description: Search for usage of getIndictmentCase in TypeScript files

# Find TypeScript files and search for getIndictmentCase
fd -e ts -x rg -n -A 5 'getIndictmentCase'

Length of output: 2437

apps/judicial-system/backend/src/app/modules/case/case.service.ts (1)

1473-1508: LGTM!

The handleCommentUpdates function correctly handles updates to case strings based on the provided update object. It ensures that existing records are deleted, updated, or new records are created as needed. The processed properties are also removed from the update object to avoid unnecessary updates.

Copy link

codecov bot commented Sep 13, 2024

Codecov Report

Attention: Patch coverage is 58.39416% with 57 lines in your changes missing coverage. Please review.

Project coverage is 36.80%. Comparing base (c2ab2f5) to head (2041177).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
.../interceptors/limitedAccessCaseFile.interceptor.ts 33.33% 8 Missing ⚠️
...nd/src/app/modules/case/models/caseString.model.ts 33.33% 8 Missing ⚠️
...system/backend/src/app/formatters/indictmentPdf.ts 12.50% 7 Missing ⚠️
.../app/modules/case/interceptors/case.interceptor.ts 50.00% 6 Missing ⚠️
...s/Prosecutor/Indictments/Indictment/Indictment.tsx 0.00% 6 Missing ⚠️
...nterceptors/completedAppealAccessed.interceptor.ts 0.00% 5 Missing ⚠️
...tem/backend/src/app/modules/event/event.service.ts 0.00% 4 Missing ⚠️
...ystem/backend/src/app/modules/case/case.service.ts 82.35% 3 Missing ⚠️
...m/api/src/app/modules/case/dto/updateCase.input.ts 0.00% 2 Missing ⚠️
...stem/api/src/app/modules/case/models/case.model.ts 0.00% 2 Missing ⚠️
... and 6 more
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main   #16010      +/-   ##
==========================================
+ Coverage   36.76%   36.80%   +0.04%     
==========================================
  Files        6731     6729       -2     
  Lines      138072   137925     -147     
  Branches    39243    39181      -62     
==========================================
+ Hits        50765    50768       +3     
+ Misses      87307    87157     -150     
Flag Coverage Δ
judicial-system-api 19.37% <37.50%> (+0.02%) ⬆️
judicial-system-backend 55.20% <64.00%> (+0.03%) ⬆️
judicial-system-formatters 79.85% <100.00%> (+0.02%) ⬆️
judicial-system-message 66.86% <ø> (ø)
judicial-system-message-handler 47.71% <ø> (ø)
judicial-system-scheduler 69.03% <100.00%> (+0.02%) ⬆️
judicial-system-types 48.26% <0.00%> (-0.09%) ⬇️
judicial-system-web 28.71% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
...l-system/backend/src/app/messages/pdfIndictment.ts 100.00% <ø> (ø)
...em/backend/src/app/modules/case/case.controller.ts 84.42% <100.00%> (+0.05%) ⬆️
...backend/src/app/modules/case/dto/updateCase.dto.ts 86.60% <100.00%> (+0.12%) ⬆️
.../backend/src/app/modules/case/guards/rolesRules.ts 45.76% <ø> (ø)
.../modules/case/interceptors/caseList.interceptor.ts 42.85% <100.00%> (+5.35%) ⬆️
...e/interceptors/caseOriginalAncestor.interceptor.ts 100.00% <100.00%> (ø)
...nd/src/app/modules/case/internalCase.controller.ts 97.60% <100.00%> (+0.01%) ⬆️
...c/app/modules/case/limitedAccessCase.controller.ts 97.60% <100.00%> (+0.01%) ⬆️
.../src/app/modules/case/limitedAccessCase.service.ts 72.07% <100.00%> (ø)
...c/app/modules/case/test/createTestingCaseModule.ts 100.00% <100.00%> (ø)
... and 21 more

... and 14 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c2ab2f5...2041177. Read the comment docs.

@datadog-island-is
Copy link

datadog-island-is bot commented Sep 13, 2024

Datadog Report

All test runs 12ec77b 🔗

9 Total Test Services: 0 Failed, 9 Passed
🔻 Test Sessions change in coverage: 2 decreased, 5 increased, 5 no change

Test Services
Service Name Failed Known Flaky New Flaky Passed Skipped Total Time Code Coverage Change Test Service View
judicial-system-api 0 0 0 57 0 6.13s 1 increased (+0.01%) Link
judicial-system-backend 0 0 0 21205 0 18m 47.67s 1 increased (+0.02%) Link
judicial-system-formatters 0 0 0 36 0 5.36s 1 increased (+0.02%) Link
judicial-system-message 0 0 0 31 0 11.36s 1 no change Link
judicial-system-message-handler 0 0 0 4 0 3.75s 1 no change Link
judicial-system-scheduler 0 0 0 4 0 4.21s 1 increased (+0.02%) Link
judicial-system-types 0 0 0 23 0 7.48s 1 decreased (-0.1%) Link
judicial-system-web 0 0 0 338 0 1m 8.92s 1 decreased (-0.02%) Link
judicial-system-xrd-api 0 0 0 6 0 5.05s 1 increased (+0.02%) Link

🔻 Code Coverage Decreases vs Default Branch (2)

  • judicial-system-types - jest 52.08% (-0.1%) - Details
  • judicial-system-web - jest 32.96% (-0.02%) - Details

@oddsson oddsson added the automerge Merge this PR as soon as all checks pass label Sep 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Merge this PR as soon as all checks pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants