-
Notifications
You must be signed in to change notification settings - Fork 61
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
feat(j-s): Civil Demands #16010
Conversation
WalkthroughThe 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 Changes
Possibly related PRs
Recent review detailsConfiguration used: .coderabbit.yaml Files selected for processing (1)
Files skipped from review due to trivial changes (1)
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
Documentation and Community
|
There was a problem hiding this 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 fromObservable<Case>
toObservable
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
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
toStringType
and the addition of theCIVIL_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 memberCIVIL_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 theCase
type in this file.
16-16
: LGTM!Removing the return type declaration
Promise<Observable<unknown>>
from theintercept
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
asCase
enhances type safety and clarity regarding the expected structure of thecase
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 thecanLimitedAcccessUserViewCaseFile
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 theNestInterceptor
interface and uses thetransformCase
function to augment the case object with additional properties. The use of RxJSmap
operator to transform the response data is a good practice.
29-38
: LGTM!The
CasesInterceptor
correctly implements theNestInterceptor
interface and uses thetransformCase
function to augment each case object in the array with additional properties. The use of RxJSmap
operator to transform the response data is a good practice.
13-20
: LGTM!The
transformCase
function correctly transforms the case object by addingpostponedIndefinitelyExplanation
andcivilDemands
properties. The use of theCaseString
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
, andisPrisonStaffUser
) 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
andcivilDemands
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 thefind
method and the optional chaining operator to safely access thevalue
property.
55-58
: LGTM!The
stringType
property is correctly defined using the@Column
decorator with theDataType.ENUM
and thevalues
option set toObject.values(StringType)
. This ensures that the property can only have values defined in theStringType
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 theDataType.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 ofCaseString
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
toconst
fordefenderCaseFileCategoriesForIndictmentCases
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
fromexport const
toconst
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 newcanLimitedAcccessUserViewCaseFile
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:
- Clear separation of conditions for different user roles (defense users and prison admin users), making the logic easy to follow and maintain.
- Use of type-safe parameters and return values, ensuring that the function is used correctly and preventing potential runtime errors.
- 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 ofCommentType
andStringType
in the codebase.The changes involve removing the export of
CommentType
and adding the export ofStringType
. This suggests thatCommentType
is no longer used in the codebase andStringType
is being used instead.Run the following script to verify the usage of
CommentType
andStringType
: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 thepostponedIndefinitelyExplanation
method.The code change to derive the
postponedIndefinitelyExplanation
using theCaseString.postponedIndefinitelyExplanation
method withtheCase.caseStrings
as an argument looks good. The syntax is correct and consistent with the importedCaseString
model.However, please verify that the logic within the
postponedIndefinitelyExplanation
method in theCaseString
model correctly constructs the explanation based on thecaseStrings
data, as this might have changed from the previous implementation usingexplanatoryComments
.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 theCase
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
toCaseString
is consistent with the overall refactoring mentioned in the PR summary.
Line range hint
117-122
: LGTM!The provider configuration change from
ExplanatoryComment
toCaseString
aligns with the overall refactoring mentioned in the PR summary.
167-168
: LGTM!The change in the retrieval of the model instance from
ExplanatoryComment
toCaseString
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 theprosecutorFields
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 thecivilDemands
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 3Length 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 thepostponedIndefinitelyExplanation
extraction, streamlines thecaseTransformer
method by reducing the complexity of the constructed case object.This change suggests that:
- The handling of postponed cases may now be less detailed, or this information is no longer necessary for the current functionality.
- 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 theUpdateCaseInput
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 thegetById
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 theupdate
method follows NestJS best practices and is consistent with the changes made to thegetById
method.
152-152
: LGTM!The addition of the
CaseInterceptor
to the@UseInterceptors
decorator for thetransition
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
toStringType
aligns with the overall shift towards a more generalized string management approach in the codebase.
119-119
: Looks good!Replacing
commentTypes
withstringTypes
is in line with the transition fromCommentType
toStringType
. This change maintains consistency throughout the codebase.
217-217
: LGTM!Filtering
CaseString
records based on thestringType
field aligns perfectly with the transition toStringType
and the usage of thestringTypes
array. This ensures that only relevant records are included.
214-215
: Verify the impact of replacingExplanatoryComment
withCaseString
.The change from
ExplanatoryComment
toCaseString
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
withCaseString
verifiedThe change from
ExplanatoryComment
toCaseString
has been implemented consistently across the codebase. No references toExplanatoryComment
were found, whileCaseString
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 5Length 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 theCase
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'supdate
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
andcivilDemands
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 whenworkingCase.demands
isundefined
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
andvalidateAndSendToServer
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 thecreate
method is a good practice for enhancing the functionality of the case creation endpoint.
85-85
: LGTM!The addition of the
CasesInterceptor
to thegetIndictmentCases
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
tocase/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 fromPromise<Case | null>
toPromise<Case>
, suggesting that the method will no longer returnnull
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 intentionalThe verification process confirms that the return type change from
Promise<Case | null>
toPromise<Case>
for thegetIndictmentCase
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 typePromise<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 5Length 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 newCaseString
model and the transition away fromExplanatoryComment
.
31-31
: LGTM!The addition of the
CaseString
model import is necessary to support the transition from theExplanatoryComment
model toCaseString
, as mentioned in the high-level summary.
76-76
: LGTM!The renaming of the variable from
mockExplanatoryCommentModel
tomockCaseStringModel
is appropriate to align with the transition from theExplanatoryComment
model toCaseString
, as mentioned in the high-level summary.
87-87
: LGTM!The destructuring of
caseStringModel
from thecreateTestingCaseModule
function is appropriate and aligns with the previous changes related to the transition to theCaseString
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 correctstringType
andvalue
, 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 theCaseInterceptor
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 theCaseInterceptor
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 theCaseInterceptor
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 theCaseListInterceptor
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 theCompletedAppealAccessedInterceptor
andCaseInterceptor
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 theCasesInterceptor
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 usesPromise.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 theCaseInterceptor
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 theCaseInterceptor
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 toCaseString
model looks good!The change from
explanatoryComments
associated withExplanatoryComment
model tocaseStrings
associated withCaseString
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 theCaseString
model.
149-150
: LGTM!The
CaseString
model is correctly injected into theInternalCaseService
constructor and assigned to thecaseStringModel
property.
394-400
: LGTM!The
CaseString
model is correctly included in the query to find a case for archiving, and thecaseStrings
are ordered by thecreated
field in ascending order.
460-472
: LGTM!The
caseStrings
are correctly archived by:
- Collecting the encryption properties of the
caseStrings
.- Updating the
caseStrings
with the cleared properties.- Adding the archived
caseStrings
to thecaseStringsArchive
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 ofPromise<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 providedupdate
object. It ensures that existing records are deleted, updated, or new records are created as needed. The processed properties are also removed from theupdate
object to avoid unnecessary updates.
apps/judicial-system/backend/migrations/20240909194458-rename-explanatory-comment.js
Show resolved
Hide resolved
Datadog ReportAll test runs ✅ 9 Total Test Services: 0 Failed, 9 Passed Test Services
🔻 Code Coverage Decreases vs Default Branch (2) |
Civil Demands
Bótakrafa - bæta við einkaréttarkröfureit á ákæruskjáinn
What
Why
Screenshots / Gifs
Checklist:
Summary by CodeRabbit
Release Notes
New Features
civilDemands
, to various case-related inputs and models, enhancing case management capabilities.Bug Fixes
Documentation
Refactor
ExplanatoryComment
withCaseString
across multiple modules, improving data handling and structure.