feat(j-s): Enable setting civil claimants #15996
Conversation
WalkthroughThe changes involve the refactoring of components and the introduction of new functionalities related to advocates and civil claimants within the judicial system application. The Changes
Possibly related PRs
Suggested reviewers
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
|
Datadog ReportAll test runs ✅ 43 Total Test Services: 0 Failed, 41 Passed Test ServicesThis report shows up to 10 services
🔻 Code Coverage Decreases vs Default Branch (2) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
Outside diff range and nitpick comments (17)
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/createCivilClaimant.graphql (1)
1-5: LGTM! Consider returning additional fields for flexibility.The
CreateCivilClaimantmutation is well-structured and aligns with GraphQL best practices and the PR objectives. It's correctly placed within the NextJS project structure.Consider returning additional fields beyond just the
id. This could provide more flexibility for client-side operations without requiring additional queries. For example:mutation CreateCivilClaimant($input: CreateCivilClaimantInput!) { createCivilClaimant(input: $input) { id name type # Add other relevant fields } }This change would allow clients to immediately use more information about the newly created civil claimant without needing a separate query.
apps/judicial-system/web/src/components/Inputs/Input.strings.ts (2)
27-31: Approve spokesperson email label, but update descriptionThe addition of
spokespersonEmailLabelis consistent with the PR objectives and follows the existing pattern. However, the description seems to be copied from the name label.Consider updating the description to be more specific to the email field:
spokespersonEmailLabel: { id: 'judicial.system.core:defender_input.spokesperson_email_label', defaultMessage: 'Netfang réttargæslumanns', - description: 'Notaður sem titill á inputi fyrir skipaðan verjanda.', + description: 'Notaður sem titill á inputi fyrir netfang réttargæslumanns.', },
45-49: Approve spokesperson phone number label, but update descriptionThe addition of
spokespersonPhoneNumberLabelis consistent with the PR objectives and follows the existing pattern. However, the description seems to be copied from the name label.Consider updating the description to be more specific to the phone number field:
spokespersonPhoneNumberLabel: { id: 'judicial.system.core:defender_input.spokesperson_phone_number_label', defaultMessage: 'Símanúmer réttargæslumanns', - description: 'Notaður sem titill á inputi fyrir skipaðan verjanda.', + description: 'Notaður sem titill á inputi fyrir símanúmer réttargæslumanns.', },apps/judicial-system/web/src/components/Inputs/InputNationalId.tsx (1)
79-79: Simplification improves code, but consider consistency and performanceThe change simplifies the code and ensures
setInputValuealways receives a defined value, which is good. However, consider the following points:
- Ensure this change doesn't alter the intended behavior if the previous condition was purposeful.
- For consistency, consider updating the
InputMaskcomponent'svalueprop to use the same pattern:value={inputValue ?? ''}.- For performance, you could potentially move the
value ?? ''logic outside theuseEffectto avoid unnecessary re-renders.Consider refactoring to improve consistency and potentially performance:
const [inputValue, setInputValue] = useState<string>('') useEffect(() => { setErrorMessage(undefined) if (value !== undefined) { setInputValue(value) } }, [value]) // ... <InputMask // ... value={inputValue} // ... > {/* ... */} </InputMask>This approach ensures consistency between the
useEffectand theInputMaskcomponent, and potentially reduces unnecessary re-renders.apps/judicial-system/web/src/routes/Court/Indictments/Defender/SelectDefender.tsx (2)
99-102: Approve changes with a suggestion for consistencyThe
InputAdvocatecomponent usage has been updated correctly to align with the PR objectives. The prop changes fromonDefenderNotFoundtoonAdvocateNotFoundand fromdefendantIdtoclientIdare appropriate and consistent with the new terminology.However, for full consistency, consider renaming the
setDefenderNotFoundfunction tosetAdvocateNotFound.Consider applying this change for consistency:
- const [defenderNotFound, setDefenderNotFound] = useState<boolean>(false) + const [advocateNotFound, setAdvocateNotFound] = useState<boolean>(false) // ... (later in the code) <InputAdvocate disabled={defendant.defenderChoice === DefenderChoice.WAIVE} - onAdvocateNotFound={setDefenderNotFound} + onAdvocateNotFound={setAdvocateNotFound} clientId={defendant.id} />
Review Remaining "Defender" Terminology for Consistency
The verification revealed multiple instances of "defender" throughout the codebase, including variable names, component names, and string literals. To ensure consistency and fully align with the PR objectives, please review and update these instances where appropriate:
Utility Files
apps/judicial-system/web/src/utils/validate.tsComponents
DefenderNotFoundDefenderInfoHooks
useDefendantsRoutes and Pages
SelectDefender.tsx- Various routes under
apps/judicial-system/web/src/routes/Court/Indictments/Defender/Tests
- Multiple test files referencing "defender"
Note: The term "defendant" is used extensively and represents a legal term that may not require changes. Please confirm whether "defendant" should remain unchanged based on its legal context.
Analysis chain
Line range hint
1-110: Consider reviewing remaining "defender" terminologyWhile the main changes have been made to transition from "defender" to "advocate", there are still instances of "defender" terminology in the code, such as:
- The
useDefendantshook- The
DefenderChoiceenum- Variable names like
defenderNotFoundanddefendantWaivesRightToCounsel- Comments and string literals containing "defender"
For consistency and to fully align with the PR objectives, consider reviewing these instances and updating them if appropriate. However, if these terms are still used in other parts of the system (e.g., backend, database), it might be necessary to keep them as is for now.
To help identify remaining instances of "defender" terminology, you can run the following command:
This will help you locate any remaining instances that might need to be updated.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for "defender" terminology in the codebase rg --type typescript --type tsx -i 'defender|defendant' apps/judicial-system/web/srcLength of output: 121
Script:
#!/bin/bash # Search for "defender" and "defendant" terminology in TypeScript and TSX files rg --type ts --type tsx -i 'defender|defendant' apps/judicial-system/web/srcLength of output: 106
Script:
#!/bin/bash # Search for "defender" and "defendant" terminology in TypeScript and TSX files rg -i 'defender|defendant' -g "*.ts" -g "*.tsx" apps/judicial-system/web/srcLength of output: 199602
apps/judicial-system/web/src/utils/hooks/useDefendants/index.ts (3)
53-56: Improved error handling and code simplificationThe changes in the
deleteDefendantfunction are good improvements:
- The simplified return statement enhances readability.
- Adding a toast notification for errors improves user feedback.
Consider adding more specific error handling:
} catch (error) { console.error('Error deleting defendant:', error); toast.error(formatMessage(errors.deleteDefendant)); return false; }This will help with debugging by logging the specific error while maintaining the user-friendly toast message.
71-74: Improved error handling and code simplificationThe changes in the
updateDefendantfunction are good improvements:
- The simplified return statement enhances readability.
- Adding a toast notification for errors improves user feedback.
Consider adding more specific error handling:
} catch (error) { console.error('Error updating defendant:', error); toast.error(formatMessage(errors.updateDefendant)); return false; }This will help with debugging by logging the specific error while maintaining the user-friendly toast message.
Line range hint
1-124: Good adherence to NextJS and TypeScript best practicesThe overall structure of this custom hook adheres well to NextJS best practices and makes good use of TypeScript:
- Custom hook pattern is used effectively for reusable logic.
- GraphQL mutations are used for efficient state management.
- TypeScript is applied for type safety in function parameters and return types.
Consider using more specific types for the
dataobject in GraphQL mutation responses. For example:interface DeleteDefendantResponse { deleteDefendant?: { deleted: boolean; }; } const { data } = await deleteDefendantMutation<DeleteDefendantResponse>({ variables: { input: { caseId, defendantId } }, });This would provide better type safety and autocompletion when working with mutation responses.
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/processing.strings.ts (3)
70-76: LGTM with a minor suggestion: Update description for accuracyThe
civilClaimantShareFilesWithDefendermessage is well-defined and uses a select statement to handle different defender types, which is good for localization. However, there's a minor inconsistency in the description.Consider updating the description to accurately reflect this message:
- 'Notaður sem texti fyrir kröfuhafi í "Kröfuhafi er ekki með íslenska kennitölu" í einkaréttarkröfu á Málsmeðferðarskjánum.', + 'Notaður sem texti fyrir valmöguleika að deila gögnum með lögmanni eða réttargæslumanni kröfuhafa í einkaréttarkröfu á Málsmeðferðarskjánum.',
89-94: LGTM with a suggestion: Clarify the purpose of the 'remove' messageThe
removemessage is well-defined, but its purpose might be confused withremoveDefender. To improve clarity:Consider updating the message ID and description to be more specific:
- id: 'judicial.system.indictments:processing.remove', + id: 'judicial.system.indictments:processing.remove_claimant', defaultMessage: 'Eyða', description: - 'Notaður sem texti í takka til að eyða kröfuhafa í einkaréttarkröfu á Málsmeðferðarskjánum.', + 'Notaður sem texti í takka til að eyða kröfuhafa (ekki lögmanni kröfuhafa) í einkaréttarkröfu á Málsmeðferðarskjánum.',
113-119: LGTM with a suggestion: Enhance consistency in the tooltip messageThe
civilClaimantShareFilesWithDefenderTooltipmessage is well-defined and provides helpful context for users. However, there's a minor inconsistency with the earliercivilClaimantShareFilesWithDefendermessage.Consider updating the default message to account for both lawyer and legal rights protector roles:
defaultMessage: - 'Ef hakað er í þennan reit fær lögmaður kröfuhafa aðgang að gögnum málsins', + 'Ef hakað er í þennan reit fær lögmaður eða réttargæslumaður kröfuhafa aðgang að gögnum málsins',This change would make the tooltip consistent with the flexibility provided in the
civilClaimantShareFilesWithDefendermessage.apps/judicial-system/web/src/components/DefenderInfo/DefenderInfo.tsx (2)
96-96: LGTM:InputAdvocatecomponent integrated correctlyThe
InputAdvocatecomponent has been correctly integrated, maintaining the same functionality as the previousDefenderInputcomponent. This change aligns with the PR objectives of generalizing the concept from defenders to advocates.Consider updating the state variable name
defenderNotFoundtoadvocateNotFoundfor consistency with the new terminology. This would involve changing:-const [defenderNotFound, setDefenderNotFound] = useState<boolean>(false) +const [advocateNotFound, setAdvocateNotFound] = useState<boolean>(false) -<InputAdvocate onAdvocateNotFound={setDefenderNotFound} /> +<InputAdvocate onAdvocateNotFound={setAdvocateNotFound} />This change would improve the consistency of the terminology throughout the component.
Line range hint
1-205: LGTM: Implementation is compatible with NextJS best practicesThe component follows React best practices which align well with NextJS recommendations. The use of functional components and hooks is consistent with modern React and NextJS development patterns.
Consider memoizing the
DefenderInfocomponent usingReact.memoif it's likely to re-render frequently due to parent component updates. This can potentially improve performance in a NextJS application:import React, { memo } from 'react' // ... rest of the imports const DefenderInfo: FC<Props> = memo(({ workingCase, setWorkingCase }) => { // ... component implementation }) export default DefenderInfoThis optimization can help prevent unnecessary re-renders and improve the overall performance of your NextJS application.
apps/judicial-system/web/src/utils/validate.ts (2)
274-282: LGTM with suggestions for improvementThe addition of
allCivilClaimantsAreValidenhances the validation process for civil claimants, which aligns well with the PR objectives. However, I have a few suggestions for improvement:
Consider using a more robust method for validating the national ID. The current implementation assumes a 10-digit format without hyphens, which might not cover all valid cases.
Add a type annotation for better type safety:
const allCivilClaimantsAreValid: boolean = workingCase.hasCivilClaims ? workingCase.civilClaimants?.every( (civilClaimant) => civilClaimant.name && (civilClaimant.noNationalId || (civilClaimant.nationalId && civilClaimant.nationalId.replace('-', '').length === 10)), ) ?? false : true
- Consider adding a comment explaining the purpose of this validation:
// Validate all civil claimants have a name and either a valid national ID or no national ID const allCivilClaimantsAreValid: boolean = ...
274-288: Overall assessment: Well-implemented feature additionThe changes to the
isProcessingStepValidIndictmentsfunction effectively implement the new feature for validating civil claimants. The implementation is focused, adheres to TypeScript best practices, and aligns well with the PR objectives. The new validation logic is properly integrated into the existing function without introducing side effects to other parts of the file.Consider implementing the suggested improvements for robustness and clarity. Additionally, ensure that corresponding updates are made to the documentation as mentioned in the PR summary.
To further enhance the modularity and reusability of the validation logic, consider extracting the civil claimant validation into a separate function. This would make it easier to test and potentially reuse in other parts of the application if needed.
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts (1)
96-99: Avoid unnecessary type assertion with 'as CivilClaimant'The type assertion
as CivilClaimantmay mask underlying type issues and reduces the benefits of TypeScript's type checking.Ensure that the object conforms to the
CivilClaimanttype without requiring an explicit type assertion:newCivilClaimants[indexOfCivilClaimantToUpdate] = { ...newCivilClaimants[indexOfCivilClaimantToUpdate], ...update, - } as CivilClaimant + }If TypeScript raises a type error, consider refining the types of
updateor adjusting theCivilClaimantinterface to accurately represent the data structure.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (15)
- apps/judicial-system/web/src/components/DefenderInfo/DefenderInfo.tsx (2 hunks)
- apps/judicial-system/web/src/components/Inputs/Input.strings.ts (3 hunks)
- apps/judicial-system/web/src/components/Inputs/InputAdvocate.tsx (13 hunks)
- apps/judicial-system/web/src/components/Inputs/InputNationalId.tsx (1 hunks)
- apps/judicial-system/web/src/components/index.ts (1 hunks)
- apps/judicial-system/web/src/routes/Court/Indictments/Defender/SelectDefender.tsx (2 hunks)
- apps/judicial-system/web/src/routes/Court/Indictments/Subpoena/Subpoena.tsx (1 hunks)
- apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (5 hunks)
- apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/processing.strings.ts (1 hunks)
- apps/judicial-system/web/src/utils/hooks/useCivilClaimants/createCivilClaimant.graphql (1 hunks)
- apps/judicial-system/web/src/utils/hooks/useCivilClaimants/deleteCivilClaimant.graphql (1 hunks)
- apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts (1 hunks)
- apps/judicial-system/web/src/utils/hooks/useCivilClaimants/updateCivilClaimant.graphql (1 hunks)
- apps/judicial-system/web/src/utils/hooks/useDefendants/index.ts (2 hunks)
- apps/judicial-system/web/src/utils/validate.ts (1 hunks)
Files skipped from review due to trivial changes (1)
- apps/judicial-system/web/src/routes/Court/Indictments/Subpoena/Subpoena.tsx
Additional context used
Path-based instructions (14)
apps/judicial-system/web/src/components/DefenderInfo/DefenderInfo.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/web/src/components/Inputs/Input.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/Inputs/InputAdvocate.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/web/src/components/Inputs/InputNationalId.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/web/src/components/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/web/src/routes/Court/Indictments/Defender/SelectDefender.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/web/src/routes/Prosecutor/Indictments/Processing/Processing.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/web/src/routes/Prosecutor/Indictments/Processing/processing.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/utils/hooks/useCivilClaimants/createCivilClaimant.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/web/src/utils/hooks/useCivilClaimants/deleteCivilClaimant.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/web/src/utils/hooks/useCivilClaimants/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/web/src/utils/hooks/useCivilClaimants/updateCivilClaimant.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/web/src/utils/hooks/useDefendants/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/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."
Learnings (1)
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (1)
Learnt from: gudjong PR: island-is/island.is#15421 File: apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx:55-61 Timestamp: 2024-07-03T15:43:13.884Z Learning: The `updateCase` method in the `apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx` file has its own error handling, and additional error handling in the `initialize` function is not necessary.
Additional comments not posted (20)
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/updateCivilClaimant.graphql (1)
1-5: LGTM! The mutation structure looks good.The mutation follows GraphQL naming conventions and has a clear purpose. Good job on keeping the input type name consistent with the "Input" suffix convention.
Consider returning more fields for flexibility.
Currently, the mutation only returns the
idof the updated civil claimant. While this might be sufficient for basic use cases, consider returning more fields (e.g.,name,status) to provide more information to the client without requiring additional queries.Reminder: Ensure proper error handling is implemented.
While error handling isn't visible in this GraphQL schema, it's crucial to implement proper error handling in the resolver function. Make sure to catch and handle potential errors, such as validation failures or database errors, and return appropriate error messages to the client.
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/deleteCivilClaimant.graphql (1)
1-5: The GraphQL mutation looks well-structured and aligns with the PR objectives.The
DeleteCivilClaimantmutation is correctly defined and follows GraphQL best practices:
- It uses a clear, descriptive name that indicates its purpose.
- It accepts an input object, which is a good practice for mutations with multiple parameters.
- The response includes a
deletedfield, which provides a clear indication of the operation's success.This mutation aligns well with the PR objective of enhancing the system to manage civil claimants. It provides the necessary functionality to remove a civil claimant from the system.
To ensure this mutation is properly integrated and used within the NextJS application, let's verify its usage:
This will help us confirm that the mutation is being imported and used correctly in the NextJS components or hooks.
Verification successful
Mutation
DeleteCivilClaimantis properly integrated and used across the codebase.The search results indicate that
DeleteCivilClaimantis correctly imported and utilized within the following files:
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.tsapps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsxThis confirms that the mutation is correctly integrated and operational within the NextJS application.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for the usage of DeleteCivilClaimant mutation in the codebase # Search for import or usage of DeleteCivilClaimant rg --type typescript --type tsx "DeleteCivilClaimant|deleteCivilClaimant" apps/judicial-system/web/srcLength of output: 139
Script:
#!/bin/bash # Description: Check for the usage of DeleteCivilClaimant mutation in the codebase # Search for import or usage of DeleteCivilClaimant in .ts and .tsx files rg "DeleteCivilClaimant|deleteCivilClaimant" -g "*.ts" -g "*.tsx" apps/judicial-system/web/srcLength of output: 1663
apps/judicial-system/web/src/components/Inputs/Input.strings.ts (3)
10-14: New spokesperson name label looks goodThe addition of
spokespersonNameLabelaligns with the PR objectives and follows the existing pattern for label definitions. The ID, default message, and description are appropriately set.
Line range hint
1-56: Overall consistency and adherence to guidelinesThe changes in this file maintain consistency with the existing code structure and adhere to the provided coding guidelines. The use of TypeScript and
react-intlfor internationalization follows NextJS best practices.
3-3: Approve export name change, but verify importsThe change from
defenderInputtostringsmakes the export more generic, which is good for reusability. However, ensure that all imports of this constant in other files are updated accordingly.To verify the impact of this change, run the following script:
Verification successful
Import verification successful
All imports of
defenderInputhave been updated tostrings, ensuring consistency across the codebase.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all imports of the previous constant name 'defenderInput' # Test: Search for imports of 'defenderInput'. Expect: No results if all imports have been updated. rg --type typescript "import.*defenderInput.*from.*Input\.strings"Length of output: 103
Script:
#!/bin/bash # Description: Find all imports of the previous constant name 'defenderInput' # Test: Search for imports of 'defenderInput'. Expect: No results if all imports have been updated. rg --type ts "import.*defenderInput.*from.*Input\.strings"Length of output: 60
apps/judicial-system/web/src/routes/Court/Indictments/Defender/SelectDefender.tsx (2)
11-11: LGTM: Import statement updated correctlyThe import statement has been updated from
DefenderInputtoInputAdvocate, which aligns with the PR objectives of transitioning terminology from "defenders" to "advocates". This change is consistent with the component usage later in the file.
Line range hint
1-110: Summary: Changes align with PR objectives, minor improvements suggestedThe changes in this file successfully implement the transition from "defender" to "advocate" terminology as per the PR objectives. The code adheres to NextJS and React best practices, and the modifications are consistent with the intended functionality.
A few minor suggestions have been made for further improving consistency:
- Renaming the
setDefenderNotFoundfunction tosetAdvocateNotFound.- Reviewing and potentially updating remaining instances of "defender" terminology throughout the file.
These suggestions are not critical and don't impact the overall functionality of the component. Great job on implementing the required changes!
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/processing.strings.ts (9)
52-57: LGTM: Appropriate replacement forhasCivilClaimsThe new
isCivilClaimmessage is a suitable replacement for the removedhasCivilClaims. It maintains consistency with the existing style and aligns with the PR objectives of refactoring terminology.
58-63: LGTM: New message for civil claimantThe
civilClaimantmessage is well-defined and consistent with the existing style. It supports the PR objectives by providing a label for civil claimants in the UI.
64-69: LGTM: Handling claimants without Icelandic national IDThe
civilClaimantNoNationalIdmessage is well-defined and addresses a specific case for claimants without an Icelandic national ID. This addition enhances the flexibility of the system in handling various claimant scenarios.
77-82: LGTM: New message for adding a claimant's lawyerThe
addDefendermessage is well-defined and consistent with the existing style. It supports the PR objectives by providing a label for adding a lawyer for the civil claimant in the UI.
83-88: LGTM: New message for removing a claimant's lawyerThe
removeDefendermessage is well-defined and consistent with the existing style. It complements theaddDefendermessage, providing a complete set of actions for managing a claimant's legal representation.
95-100: LGTM: New message for adding a civil claimantThe
addCivilClaimantmessage is well-defined and consistent with the existing style. It directly supports the PR objectives by providing a label for adding civil claimants in the UI.
101-106: LGTM: New message for lawyer labelThe
lawyermessage is well-defined and consistent with the existing style. It supports the PR objectives by providing a label for lawyers in the UI, aligning with the terminology refactor from "defenders" to "advocates".
107-112: LGTM: New message for legal rights protector labelThe
legalRightsProtectormessage is well-defined and consistent with the existing style. It supports the PR objectives by providing a label for legal rights protectors in the UI, enhancing the system's flexibility in representing different types of legal advocates.
Line range hint
1-119: Overall assessment: Well-implemented changes supporting PR objectivesThe changes in this file effectively support the PR objectives of enabling the setting of civil claimants and refactoring terminology from "defenders" to "advocates". The new messages are well-structured, consistent with the existing style, and provide the necessary language support for the enhanced functionality.
Key points:
- All new messages align with the PR objectives.
- The changes maintain consistency with the existing code style.
- The new messages provide flexibility in handling different types of legal advocates.
- A few minor suggestions were made to improve clarity and consistency.
These changes significantly enhance the system's ability to handle civil claimants and their legal representatives, improving the overall functionality of the judicial system application.
apps/judicial-system/web/src/components/index.ts (1)
45-47: LGTM! Changes align with PR objectives and improve component granularity.The addition of
InputAdvocate,InputName, andInputNationalIdexports aligns well with the PR objective of transitioning from "defenders" to "advocates" terminology. This more granular approach to input components can improve reusability and maintainability.To ensure the removal of
DefenderInputdoesn't cause issues, let's verify its usage:apps/judicial-system/web/src/components/DefenderInfo/DefenderInfo.tsx (2)
20-21: LGTM: Import statements updated correctlyThe import statements have been updated to reflect the replacement of
DefenderInputwithInputAdvocate. This change is consistent with the PR objectives and maintains the correct module structure.
Line range hint
1-205: LGTM: TypeScript usage is correct and follows best practicesThe TypeScript implementation in this file is well-done. Props are properly typed using an interface, and imported types are used appropriately throughout the component. This ensures type safety and improves code maintainability.
apps/judicial-system/web/src/utils/validate.ts (1)
288-288: LGTM: Proper integration of new validationThe addition of
allCivilClaimantsAreValidto the return statement's Boolean check is appropriate. It ensures that the processing step is only considered valid when all civil claimants are valid, in addition to the existing checks. This change is consistent with the function's purpose and aligns well with the PR objectives.
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/deleteCivilClaimant.graphql
Show resolved
Hide resolved
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts
Outdated
Show resolved
Hide resolved
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts
Outdated
Show resolved
Hide resolved
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts
Outdated
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Outdated
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Outdated
Show resolved
Hide resolved
apps/judicial-system/web/src/components/Inputs/InputAdvocate.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I like where you are going with this PR, creating a shared component to handle lawyer lookups. However, I feel the shared component knows too much about the components that use it. A better approach would be to make the component oblivious of the using components and inject all relevant update methods.
I think the component works as is and the changes suggested above chould be done later as part of a cooldown week.
There was a problem hiding this comment.
Actionable comments posted: 4
Outside diff range and nitpick comments (9)
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts (4)
25-46: LGTM with a minor suggestion: createCivilClaimant functionThe
createCivilClaimantfunction is well-implemented with proper error handling and performance optimization usinguseCallback. The function now returns a value in all code paths, addressing a previous concern.Consider adding an explicit return type annotation to the function for improved type safety:
const createCivilClaimant = useCallback( - async (civilClaimant: CreateCivilClaimantInput) => { + async (civilClaimant: CreateCivilClaimantInput): Promise<string | null> => { // ... function body ... }, [createCivilClaimantMutation, formatMessage, isCreatingCivilClaimant], )
48-62: LGTM with a suggestion: deleteCivilClaimant functionThe
deleteCivilClaimantfunction is well-implemented with proper error handling and consistent return values. The use ofuseCallbackfor performance optimization is commendable.Consider adding an explicit return type annotation to the function for improved type safety:
const deleteCivilClaimant = useCallback( - async (caseId: string, civilClaimantId: string) => { + async (caseId: string, civilClaimantId: string): Promise<boolean> => { // ... function body ... }, [deleteCivilClaimantMutation, formatMessage], )
64-80: LGTM with a suggestion: updateCivilClaimant functionThe
updateCivilClaimantfunction is well-implemented with proper error handling and consistent return values. The use ofuseCallbackfor performance optimization is appropriate.Consider adding an explicit return type annotation to the function for improved type safety:
const updateCivilClaimant = useCallback( - async (updateCivilClaimant: UpdateCivilClaimantInput) => { + async (updateCivilClaimant: UpdateCivilClaimantInput): Promise<boolean> => { // ... function body ... }, [formatMessage, updateCivilClaimantMutation], )
1-133: Overall assessment: Well-implemented custom hook with minor improvements neededThe
useCivilClaimantshook is generally well-implemented, adhering to React and TypeScript best practices. Key strengths include:
- Proper use of
useCallbackfor performance optimization.- Consistent error handling with user-friendly notifications.
- Clean and intuitive API for consumers.
Main points to address:
- Verify the existence of generated mutation hook files.
- Add explicit return type annotations to functions for improved type safety.
- Update
setAndSendCivilClaimantToServerto properly handle the asynchronousupdateCivilClaimantfunction.Addressing these points will further enhance the quality and reliability of the implementation.
Consider adding unit tests for this custom hook to ensure its reliability and ease of maintenance as the application evolves.
apps/judicial-system/web/messages/Core/errors.ts (1)
15-20: LGTM with a minor suggestion.The new
updateCivilClaimanterror message is well-structured and consistent with other error messages in the file. It follows the established pattern and provides a clear message in Icelandic.Consider updating the description to be more specific:
- 'Notaður sem villuskilaboð þegar ekki gengur að uppfæra kröfuhafa', + 'Notaður sem villuskilaboð þegar ekki gengur að uppfæra upplýsingar um kröfuhafa',This change would make the description slightly more precise about what is being updated.
apps/judicial-system/web/src/components/Inputs/InputAdvocate.tsx (4)
30-43: LGTM! Consider using an enum for advocate types.The changes to the imports and the
Propsinterface effectively support the expanded functionality of theInputAdvocatecomponent. The addition ofadvocateTypeandisCivilClaimprops provides the necessary flexibility to handle different types of advocates and cases.Consider defining an enum for the
advocateTypeprop to improve type safety and maintainability:enum AdvocateType { Defender = 'defender', Spokesperson = 'spokesperson', LegalRightsProtector = 'legal_rights_protector' } // Then update the Props interface: advocateType?: AdvocateType;This change would make it easier to manage and extend advocate types in the future.
Line range hint
120-196: LGTM! Consider extracting the lawyer update logic.The
handleLawyerChangefunction has been effectively updated to handle both defenders and spokespersons, including new logic for civil claimants. The use of theisCivilClaimprop to determine the appropriate action is a good approach.Consider extracting the lawyer update logic into a separate function to improve readability and maintainability:
const updateLawyerInfo = (selectedOption: SingleValue<ReactSelectOption>) => { if (!selectedOption) return { lawyer: {}, spokesperson: {} }; const { label, value, __isNew__: defenderNotFound } = selectedOption; const lawyer = lawyers.find((l: Lawyer) => l.email === (value as string)); return { lawyer: { defenderName: lawyer ? lawyer.name : label, defenderNationalId: lawyer ? lawyer.nationalId : '', defenderEmail: lawyer ? lawyer.email : '', defenderPhoneNumber: lawyer ? lawyer.phoneNr : '', }, spokesperson: { spokespersonName: lawyer ? lawyer.name : label, spokespersonNationalId: lawyer ? lawyer.nationalId : '', spokespersonEmail: lawyer ? lawyer.email : '', spokespersonPhoneNumber: lawyer ? lawyer.phoneNr : '', }, defenderNotFound, }; }; // Then in handleLawyerChange: const { lawyer: updatedLawyer, spokesperson: updatedSpokesperson, defenderNotFound } = updateLawyerInfo(selectedOption); onAdvocateNotFound?.(defenderNotFound || false);This refactoring would make the
handleLawyerChangefunction more concise and easier to understand.Tools
Biome
[error] 143-143: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
Line range hint
244-311: LGTM! Consider using a strategy pattern for advocate updates.The
handleLawyerPropertyChangeandhandleLawyerPropertyBlurfunctions have been effectively updated to handle both civil claimants and defendants. The use of theisCivilClaimprop to determine the appropriate action is a good approach, and the error handling and validation logic remain consistent.To further improve the code's maintainability and extensibility, consider implementing a strategy pattern for advocate updates:
const advocateUpdateStrategies = { civilClaimant: { updateState: updateCivilClaimantState, update: updateCivilClaimant, getIdProp: () => 'civilClaimantId', }, defendant: { updateState: updateDefendantState, update: updateDefendant, getIdProp: () => 'defendantId', }, }; const getStrategy = (isCivilClaim) => isCivilClaim ? advocateUpdateStrategies.civilClaimant : advocateUpdateStrategies.defendant; // Then in handleLawyerPropertyChange: const strategy = getStrategy(isCivilClaim); strategy.updateState( { ...update, caseId: workingCase.id, [strategy.getIdProp()]: clientId }, setWorkingCase, ); // Similarly in handleLawyerPropertyBlur: const strategy = getStrategy(isCivilClaim); strategy.update({ ...update, caseId, [strategy.getIdProp()]: clientId });This approach would make it easier to add new types of advocates in the future and reduce the need for conditional statements.
Line range hint
315-496: LGTM! Consider extracting label logic for improved readability.The render logic has been effectively updated to handle different types of advocates, using conditional rendering based on
advocateTypeandisCivilClaimprops. The dynamic labels and placeholders provide the necessary flexibility for different scenarios.To improve readability, consider extracting the label logic into separate functions:
const getNameLabel = (advocateType, sessionArrangements) => { if (advocateType === 'legal_rights_protector') { return formatMessage(strings.spokespersonNameLabel); } return formatMessage(strings.nameLabel, { sessionArrangements }); }; const getEmailLabel = (advocateType, sessionArrangements) => { if (advocateType === 'legal_rights_protector') { return formatMessage(strings.spokespersonEmailLabel); } return formatMessage(strings.emailLabel, { sessionArrangements }); }; // Similar function for phone number label // Then in the render: label={getNameLabel(advocateType, workingCase.sessionArrangements)} // ... label={getEmailLabel(advocateType, workingCase.sessionArrangements)}This refactoring would make the JSX more concise and easier to read, while keeping the label logic centralized and maintainable.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (5)
- apps/judicial-system/web/messages/Core/errors.ts (1 hunks)
- apps/judicial-system/web/src/components/Inputs/InputAdvocate.tsx (13 hunks)
- apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (5 hunks)
- apps/judicial-system/web/src/utils/hooks/index.ts (1 hunks)
- apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts (1 hunks)
Additional context used
Path-based instructions (5)
apps/judicial-system/web/messages/Core/errors.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/Inputs/InputAdvocate.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/web/src/routes/Prosecutor/Indictments/Processing/Processing.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/web/src/utils/hooks/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/web/src/utils/hooks/useCivilClaimants/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."
Learnings (1)
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (1)
Learnt from: gudjong PR: island-is/island.is#15421 File: apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx:55-61 Timestamp: 2024-07-03T15:43:13.884Z Learning: The `updateCase` method in the `apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx` file has its own error handling, and additional error handling in the `initialize` function is not necessary.
Biome
apps/judicial-system/web/src/components/Inputs/InputAdvocate.tsx
[error] 143-143: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
Additional comments not posted (9)
apps/judicial-system/web/src/utils/hooks/index.ts (1)
31-31: LGTM! The new export aligns with the PR objectives and existing code structure.The addition of
useCivilClaimantsexport is consistent with the existing code style and structure in this index file. This change aligns well with the PR objective of enhancing the system to allow setting civil claimants.A few points to consider:
- The export follows NextJS best practices for file structure and module organization.
- The use of TypeScript for type safety is maintained, assuming
useCivilClaimantsis properly typed in its implementation file.- This new hook likely contributes to efficient state management for civil claimant data.
To ensure the
useCivilClaimantshook is properly implemented and typed, let's verify its implementation:Verification successful
Verified: The
useCivilClaimantshook is correctly implemented and properly integrated.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of useCivilClaimants hook # Test: Check if the useCivilClaimants file exists and its content fd --type file --full-path "apps/judicial-system/web/src/utils/hooks/useCivilClaimants.ts" --exec cat {}Length of output: 106
Script:
#!/bin/bash # Description: Verify the existence of useCivilClaimants.ts hook # Search for the useCivilClaimants.ts file in the repository fd "useCivilClaimants.ts"Length of output: 25
Script:
#!/bin/bash # Description: Search for useCivilClaimants implementation across the repository # Use ripgrep to find any instances of useCivilClaimants rg "useCivilClaimants" --type tsLength of output: 746
Script:
#!/bin/bash # Description: Display the contents of useCivilClaimants hook implementation # Display the contents of useCivilClaimants/index.ts cat "apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts"Length of output: 4125
apps/judicial-system/web/src/utils/hooks/useCivilClaimants/index.ts (2)
17-23: LGTM: Hook initializationThe initialization of the
useCivilClaimantshook follows React best practices. The use ofuseIntlfor internationalization and the proper initialization of mutation hooks are commendable.
82-111: LGTM: updateCivilClaimantState functionThe
updateCivilClaimantStatefunction is well-implemented, following React best practices for state updates. It properly handles edge cases, including whencivilClaimantsdoesn't exist and when the civil claimant ID is not found. The use of immutable update patterns with spread operators is commendable.apps/judicial-system/web/messages/Core/errors.ts (3)
27-32: LGTM! Well-structured error message.The new
createCivilClaimanterror message is correctly implemented and consistent with the existing error messages in the file. It follows the established pattern, uses appropriate Icelandic text, and provides a clear description of its usage.
15-44: Summary: Excellent addition of civil claimant error messages.The new error messages for civil claimants (
updateCivilClaimant,createCivilClaimant, anddeleteCivilClaimant) have been successfully implemented. These additions:
- Enhance the error handling capabilities for civil claimant operations.
- Maintain consistency with existing error message structures.
- Use appropriate Icelandic language for user-facing messages.
- Provide clear descriptions for developers.
These changes align well with the PR objectives of enabling the setting of civil claimants and their legal advocates. The new error messages will improve the user experience by providing specific feedback for civil claimant-related operations.
To ensure full alignment with the PR objectives, consider the following actions:
- Update relevant documentation to reflect these new error messages.
- Ensure that the components using these error messages are properly implemented.
- Add appropriate unit tests to cover scenarios where these error messages would be triggered.
39-44: LGTM! Consistent implementation with a suggestion for verification.The new
deleteCivilClaimanterror message is well-structured and follows the established pattern in the file. It uses appropriate Icelandic text and provides a clear description of its usage.Please verify that "kröfuhafa" is the correct term for "civil claimant" in this context. It might be beneficial to consult with the product owner or a domain expert to ensure the terminology aligns with the specific legal context of the application.
To assist in this verification, you can run the following script to check for consistency in terminology usage across the codebase:
This script will help identify if there are any inconsistencies in the terminology used for civil claimants across the codebase.
Verification successful
[/run_scripts]
Verified: Terminology Consistent
The term "kröfuhafa" is consistently used across the codebase for "civil claimant," ensuring uniform terminology throughout the application.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistent usage of "kröfuhafa" and related terms echo "Checking for 'kröfuhafa' usage:" rg --type typescript --type javascript "kröfuhafa" echo "\nChecking for 'civil claimant' usage:" rg --type typescript --type javascript "civil.?claimant" echo "\nChecking for other potential translations:" rg --type typescript --type javascript "stefnandi|sóknaraðili|málshefjandi"Length of output: 573
Script:
#!/bin/bash # Description: Check for consistent usage of "kröfuhafa" and related terms in .ts and .js files echo "Checking for 'kröfuhafa' usage:" rg "kröfuhafa" -g "*.ts" -g "*.js" echo "\nChecking for 'civil claimant' usage:" rg "civil.?claimant" -g "*.ts" -g "*.js" echo "\nChecking for other potential translations:" rg "stefnandi|sóknaraðili|málshefjandi" -g "*.ts" -g "*.js"Length of output: 7060
apps/judicial-system/web/src/components/Inputs/InputAdvocate.tsx (3)
69-107: LGTM! Good use of hooks and clear logic.The updates to the component function and its hooks effectively support the new functionality for handling different types of advocates. The use of separate hooks for defendants and civil claimants (
useDefendantsanduseCivilClaimants) promotes good separation of concerns. The logic for finding defendants and civil claimants is concise and clear.
Line range hint
201-241: LGTM! Clear and maintainable property handling.The updates to the
propertyValidationsandformatUpdatefunctions effectively support the new functionality for different types of advocates. The inclusion of spokesperson-related properties inpropertyValidationsand the expanded switch statement informatUpdateare clear and easy to maintain.
499-499: LGTM! Correct export of the renamed component.The export statement has been correctly updated to export
InputAdvocate, which aligns with the component's new name and expanded functionality.
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
- apps/judicial-system/web/src/components/index.ts (1 hunks)
- apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/judicial-system/web/src/components/index.ts
🧰 Additional context used
📓 Path-based instructions (1)
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.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."
📓 Learnings (1)
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (1)
Learnt from: gudjong PR: island-is/island.is#15421 File: apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx:55-61 Timestamp: 2024-07-03T15:43:13.884Z Learning: The `updateCase` method in the `apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx` file has its own error handling, and additional error handling in the `initialize` function is not necessary.
🔇 Additional comments not posted (3)
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx (3)
146-156: EnsurecivilClaimantsis always an arrayThe previous review comment about initializing the
civilClaimantsarray when it's undefined is still applicable. IfprevWorkingCase.civilClaimantsisnullorundefined, the current logic may setcivilClaimantstoundefined, causing issues when rendering or manipulating the array.
217-222: Avoid exiting the loop prematurely inremoveAllCivilClaimantsIn the
removeAllCivilClaimantsfunction, ifcivilClaimant.idis undefined, the function returns, which stops the deletion process for remaining civil claimants. This could result in some civil claimants not being deleted as expected.
472-474: Avoid resettingnationalIdNotFoundprematurelyCalling
setNationalIdNotFound(false)when the input length is less than 11 may reset thenationalIdNotFoundflag before the national ID has been validated. This could lead to incorrect validation states.
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
apps/judicial-system/web/src/routes/Prosecutor/Indictments/Processing/Processing.tsx
Show resolved
Hide resolved
* Started working on extracting nationalId input to component * Use InputNationalId in DefendantInfo * Create name input * Checkpoint * Add AddDefender button to Claimant section * Add defender info * Refactor * feat(j-s): Added controller and service for civilclaimant * Checkpoint * fix(j-s): Dtos * feat(j-s): Civil claimant API layer * Add addClaimant functionality * fix(j-s): backend usage * Checkpoint * Revert framer motion update * fix(j-s): Remove defendant and rename defender to spokesperson * Cleanup * feat(j-s): Connect civil claimant to case * fix(j-s): Remove required from name * Remove unused imports * Layout * feat(j-s): Add hasCivilClaims * feat(j-s): Fix boolean * chore(j-s): Add update civil claimant mutation to resolver * chore(j-s): Added role guards and write guards to civil claimant controller * chore(j-s): Added delete civil claimant to resolver * Save hasCivilClaims choise to server * Create new civil claimant when needd * CRUD operations on civil claimant * Fix lint * chore: nx format:write update dirty files * Create and delete civil claimant * Create and delete civil claimant * Lookup nationalId with national registry * Checkpoint * Autofill name when national id is set * Prevent double civil claimant creation * Implement noNationalId * Remove redunant boolean check * Checkpoint * Rename defendantId to clientId in DefenderInput component to make it more generic * Enable lawyer lookup * Add ability to share case files with defender * Reset lawyer when he is deleted * Remove unused code * Remove unused code * Remove unused code * Remove unused code * Remove unused code * Remove unused code * Remove unused code * Merge * Merge * Refactor DefenderInput * Clear nationalId when noNationalId is selcted * Checkpoint * Clear nationalId * Refactor DefenderInput * Fix lint * Allow clear defender * Validation * Remove console.log * Reset caseFilesSharedWithSpokesperson when advocate is set * Add tooltip * Validate name * Validate * Fix input name bug * Remove DefenderInput * Reorder imports * Remove commented out code * Validate * Fix strings * Cleanup * Cleanup * Cleanup * Cleanup * Cleanup * Use barrel file for import * Fix typo --------- Co-authored-by: unakb <una@kolibri.is> Co-authored-by: andes-it <builders@andes.is>
Enable setting civil claimants
Asana
What
Screenshots / Gifs
Checklist:
Summary by CodeRabbit
Release Notes
New Features
InputAdvocatecomponent to replace the previousDefenderInputfor enhanced advocate information handling.Enhancements
Bug Fixes
Documentation