feat(death-benefits): new application #16629
Conversation
…nal documents required
…s/island.is into feat/survivors-benefits
…s/island.is into feat/survivors-benefits
* feat(survivors-benefits): Spousal info Fetch spousal info and display it * Spouse info screen * Use spouse info data * deceased spouse info export * send in survivors benefits application * Comment out survivors benefits code send application code * move deceased spouse date to bottom * Send nationalIds of spouse and children. Also added validation for spouseInfo * date of death only for non icelandic spouses * Remove form/condition for non icelandic deceased spouse * Deceased spouse review section * chore: nx format:write update dirty files * remove unused api, fix check for death certificate and expecting child screens * Add spouseTaxCardUsage to applicationDTO * Change cohabitation length variable name * chore: nx format:write update dirty files * get updated endpoint --------- Co-authored-by: hfhelgason <[email protected]> Co-authored-by: andes-it <[email protected]> Co-authored-by: ylfahfa <[email protected]>
WalkthroughThe pull request introduces a comprehensive set of changes to the social insurance administration module, specifically enhancing the handling of death benefits applications. Key additions include new functions for processing applications, managing attachments, and retrieving relevant applicant information. Several new React components are created for rendering application details and review screens. Additionally, new API endpoints and configurations are established to support these functionalities, alongside updates to message descriptors and data schemas to accommodate the new application type. Changes
Possibly related PRs
Suggested labels
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
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 58
🧹 Outside diff range and nitpick comments (29)
libs/application/templates/social-insurance-administration/death-benefits/src/types.ts (1)
8-11: Consider adding JSDoc comments for file upload requirements
The interface structure is good, but consider adding JSDoc comments to document:
- Accepted file types
- Size limits
- Required file format for death certificates
- When expectingChild documents are required
Example enhancement:
+/**
+ * Interface for managing death benefits related file uploads
+ * @property expectingChild - Documents proving pregnancy status
+ * @property deathCertificate - Official death certificate documents
+ */
export interface FileUpload {
expectingChild?: FileType[]
deathCertificate?: FileType[]
}libs/application/templates/social-insurance-administration/death-benefits/src/index.ts (1)
1-1: Consider adding explicit type information for the template.
While the default import/export pattern is clean, adding explicit type information would improve type safety and documentation.
-import template from './lib/DeathBenefitsTemplate'
+import template from './lib/DeathBenefitsTemplate'
+import type { ApplicationTemplate } from '@island.is/application/core'
+
+const deathBenefitsTemplate: ApplicationTemplate = template
+export default deathBenefitsTemplateAlso applies to: 6-6
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx (1)
6-12: Consider adding error handling for sensitive data.
Since this component handles sensitive information about children in a death benefits application:
- Consider wrapping the component with an error boundary to gracefully handle rendering failures
- Add proper data sanitization for the children's information
- Implement loading states for when the external data is being fetched
libs/application/templates/social-insurance-administration/death-benefits/src/forms/InReview.ts (1)
10-27: Consider adding form metadata for better documentation
The form could benefit from additional metadata to improve maintainability and documentation.
Consider adding these properties to the form:
export const InReview: Form = buildForm({
id: 'DeathBenefitsInReview',
title: deathBenefitsFormMessage.shared.applicationTitle,
logo: Logo,
+ description: deathBenefitsFormMessage.shared.reviewDescription,
+ mode: 'review',
+ readOnlyMode: true,
children: [libs/clients/social-insurance-administration/src/lib/dto/application.dto.ts (1)
29-31: Add documentation and consider data validation
While the new properties are well-typed and align with the death benefits feature requirements, consider the following improvements:
- Add JSDoc comments to document the purpose and format requirements for each property
- Consider adding validation constraints for national ID formats
- Add a warning comment about PII data handling
Here's a suggested improvement:
+ /** Warning: The following properties contain PII data and should be handled according to privacy guidelines */
+
+ /** National ID of the deceased person in the format DDMMYY-XXXX */
deceasedNationalId?: string
+ /** Array of national IDs for dependent children in the format DDMMYY-XXXX */
childrenNationalIds?: string[]
+ /** Indicates how the deceased person's tax card should be handled */
spouseTaxCardUsage?: SpouseTaxCardUsagelibs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Comment.tsx (2)
1-6: Add explicit type imports for better type safety
Consider importing specific types from the UI components to enhance type safety and documentation.
-import { DataValue, ReviewGroup } from '@island.is/application/ui-components'
+import type { DataValueProps, ReviewGroupProps as BaseReviewGroupProps } from '@island.is/application/ui-components'
+import { DataValue, ReviewGroup } from '@island.is/application/ui-components'1-38: Consider enhancing component reusability
Since this is in the libs directory, consider making the Comment component more generic to be reusable across different application templates:
- Extract the message keys to props
- Make the answer extraction logic configurable
- Consider creating a generic ReviewComment component that this can extend
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Attachments.tsx (1)
1-37: Consider architectural improvements for better maintainability.
As this component handles sensitive information and needs to be reusable:
- Consider extracting the file name processing logic into a custom hook
- Add memoization for performance optimization
- Consider adding data-testid attributes for testing
Here's a suggested approach for better separation of concerns:
// useAttachmentProcessor.ts
export const useAttachmentProcessor = (attachment: Attachment) => {
return useMemo(() => {
const nameArray = attachment.name?.split('.') ?? []
const fileType = nameArray.pop()?.toUpperCase()
const fileName = sanitizeFileName(nameArray.join('.'))
return { fileName, fileType }
}, [attachment])
}This would simplify the main component and make it more testable.
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Children.tsx (1)
29-33: Simplify the template literal construction.
The current template literal with line breaks can be simplified for better readability.
- text={`
- ${formatMessage(
- socialInsuranceAdministrationMessage.confirm.nationalId,
- )}: ${formatKennitala(child.nationalId)}`}
+ text={`${formatMessage(
+ socialInsuranceAdministrationMessage.confirm.nationalId
+ )}: ${formatKennitala(child.nationalId)}`}libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/DeceasedSpouse.tsx (2)
1-10: Add type definitions for external data and application answers.
Consider defining explicit types for the data structures returned by getApplicationAnswers and getApplicationExternalData to improve type safety and maintainability.
interface DeathBenefitsAnswers {
deceasedSpouseName: string;
deceasedSpouseNationalId: string;
}
interface DeathBenefitsExternalData {
deceasedSpouseNationalId: string;
}11-15: Document props and add validation for required fields.
Add JSDoc comments to document the component's props and their purpose. Consider marking required props in the type definition.
/**
* Renders a review group for deceased spouse information
* @param {Object} props
* @param {Application} props.application - The death benefits application
* @param {boolean} props.editable - Whether the group can be edited
* @param {(screen: string) => void} props.goToScreen - Navigation callback
*/libs/clients/social-insurance-administration/src/lib/apiProvider.ts (1)
71-75: Consider implementing additional safeguards for sensitive data
Since this API handles death benefits, which involves sensitive personal and financial information:
- Consider implementing data encryption for sensitive fields
- Add audit logging for all API access
- Implement rate limiting to prevent abuse
- Add clear data retention policies
libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.type.ts (1)
73-76: Consider adding JSDoc and constraining the ratio type.
While the interface is well-structured, it would benefit from documentation and more specific typing:
+/**
+ * Represents the spouse's tax card usage preferences
+ * @property usecard - Whether to use the spouse's tax card
+ * @property ratio - The percentage of the tax card to use (0-100)
+ */
export interface SpouseTaxCardUsage {
usecard: boolean
- ratio: number
+ ratio: number & { __brand: 'Percentage' } // Or add runtime validation
}libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/BaseInformation.tsx (1)
89-90: Standardize padding patterns.
The padding prop uses different formats: paddingBottom={3} vs paddingBottom={[3, 3, 3, 0]}. Consider standardizing the responsive padding approach across all grid columns for consistency.
libs/application/templates/social-insurance-administration/death-benefits/src/forms/Prerequisites.ts (1)
83-102: Document the purpose of providers with empty titles.
Several data providers have empty titles. While this might be intentional, it's recommended to:
- Add a comment explaining why these titles are empty
- Consider using
nullinstead of empty strings to make the intention clearer
buildDataProviderItem({
provider: SocialInsuranceAdministrationApplicantApi,
- title: '',
+ // Title intentionally empty as this provider is used for data fetching only
+ title: null,
}),libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.service.ts (1)
141-147: Add 404 error handling for consistency.
Consider adding 404 error handling to match the pattern used in other methods like getPayments and getLatestIncomePlan.
Apply this diff:
async getSpousalInfo(
user: User,
): Promise<TrWebApiServicesUseCaseDeathBenefitsModelsExternalSpousalInfo> {
- return this.deathBenefitsApiWithAuth(
+ return await this.deathBenefitsApiWithAuth(
user,
- ).apiProtectedV1DeathBenefitsSpousalinfoGet()
+ ).apiProtectedV1DeathBenefitsSpousalinfoGet().catch(handle404)
}libs/feature-flags/src/lib/features.ts (1)
42-42: Consider standardizing the string value format.
While the flag name follows camelCase convention, consider updating the string value to match the predominant kebab-case format used by other application flags (e.g., 'is-death-benefits-application-enabled').
- deathBenefits = 'isdeathbenefitsapplicationenabled',
+ deathBenefits = 'is-death-benefits-application-enabled',libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.spec.ts (1)
139-162: Consider adding validation for required documents.
The tests for additional documents transitions don't verify the content of the uploaded documents. Consider adding tests to verify:
- Maximum number of documents
- Required document types
- Document size limits
- Invalid document scenarios
Add test cases like:
it('should not transition when required documents are missing', () => {
const helper = new ApplicationTemplateHelper(
buildApplication({
state: 'additionalDocumentsRequired',
answers: {
fileUploadAdditionalFiles: {
additionalDocuments: [], // empty documents
}
}
}),
DeathBenefitsTemplate,
)
const [hasChanged, newState] = helper.changeState({
type: DefaultEvents.SUBMIT,
})
expect(hasChanged).toBe(false)
expect(newState).toBe('additionalDocumentsRequired')
})Also applies to: 164-187
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/PaymentInformation.tsx (2)
21-41: Add prop validation for required fields.
While the props are properly typed, consider adding runtime validation for required fields, especially for sensitive payment information.
Consider adding prop-types or zod validation:
import { z } from 'zod'
const paymentInfoSchema = z.object({
application: z.object({
answers: z.record(z.unknown())
}).required(),
editable: z.boolean(),
goToScreen: z.function().optional()
})180-191: Add data-testid for testing tax level display.
To improve testability, consider adding data-testid attributes.
<DataValue
+ data-testid="death-benefits-tax-level"
label={formatMessage(
socialInsuranceAdministrationMessage.payment.taxLevel,
)}
value={formatMessage(getTaxLevelOption(taxLevel))}
/>libs/application/template-loader/src/lib/templateLoaders.ts (1)
178-181: LGTM! Consider grouping with other SIA templates.
The implementation follows the established patterns for template loading and properly enables tree-shaking through dynamic imports. However, for better organization, consider moving this entry next to other Social Insurance Administration templates (like OLD_AGE_PENSION, HOUSEHOLD_SUPPLEMENT, etc.) to maintain a logical grouping.
- [ApplicationTypes.HOME_SUPPORT]: () =>
- import('@island.is/application/templates/home-support'),
- [ApplicationTypes.CHANGE_MACHINE_SUPERVISOR]: () =>
- import('@island.is/application/templates/aosh/change-machine-supervisor'),
[ApplicationTypes.DEATH_BENEFITS]: () =>
import(
'@island.is/application/templates/social-insurance-administration/death-benefits'
),
+ [ApplicationTypes.HOME_SUPPORT]: () =>
+ import('@island.is/application/templates/home-support'),
+ [ApplicationTypes.CHANGE_MACHINE_SUPERVISOR]: () =>
+ import('@island.is/application/templates/aosh/change-machine-supervisor'),libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts (1)
1-183: Consider extracting common messages to a shared module.
Since this file is in the libs directory, consider extracting commonly used messages (like error states, shared UI elements) into a separate shared module to promote reuse across different application templates.
This would:
- Reduce duplication across different application templates
- Ensure consistency in messaging
- Improve maintainability
libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration-utils.ts (1)
Line range hint 1-387: Consider improving modularity and reusability
As this file is in the libs directory, consider these architectural improvements:
- Extract common DTO transformation logic into a shared utility
- Create a base transformer class that specific benefit transformers can extend
- Consider using a builder pattern for DTO construction
This would improve reusability across different NextJS apps and make the code more maintainable.
libs/application/templates/social-insurance-administration/core/src/lib/messages.ts (1)
387-393: Consider enhancing the description for death benefits context.
Since this is part of the death benefits application, consider making the message more specific about the types of documents that might be needed in this context, and add a note about handling sensitive documents.
additionalFileDescription: {
id: 'sia.application:fileUpload.additionalFile.description',
defaultMessage:
- 'Hér getur þú skilað viðbótargögnum til Tryggingastofnunar ef þú telur þörf á.',
+ 'Hér getur þú skilað viðbótargögnum til Tryggingastofnunar ef þú telur þörf á, svo sem dánarvottorð eða önnur viðeigandi skjöl. Vinsamlegast gættu þess að öll viðkvæm gögn séu send á öruggan hátt.',
description:
- 'Below you can submit additional data to the Social Insurance Administration, if need be.',
+ 'Below you can submit additional documents to the Social Insurance Administration if needed, such as death certificates or other relevant documents. Please ensure all sensitive documents are transmitted securely.',libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/index.tsx (1)
85-85: Remove unnecessary template literals in state comparisons
When comparing state to constants in States, the use of template literals is unnecessary because States.DRAFT and States.TRYGGINGASTOFNUN_SUBMITTED are already strings. Simplifying these comparisons improves readability.
Apply this diff to simplify the state comparisons:
- {state === `${States.DRAFT}` && (
+ {state === States.DRAFT && (- {state === `${States.TRYGGINGASTOFNUN_SUBMITTED}` && (
+ {state === States.TRYGGINGASTOFNUN_SUBMITTED && (Also applies to: 133-133
libs/application/templates/social-insurance-administration/death-benefits/src/lib/deathBenefitsUtils.ts (1)
309-312: Specify return type for isEligible function
For consistency and better type safety, consider adding an explicit return type to the isEligible function.
Update the function signature:
export const isEligible = (externalData: ExternalData): boolean => {
// existing function body
}libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts (1)
348-348: Non-English TODO comment detected
The TODO comment at line 348 is written in Icelandic:
// TODO: Þurfum mögulega að breyta þessu þegar við vitum hvernig TR gerir stöðubreytingarFor consistency and maintainability, please translate this comment into English. This ensures that all team members can understand and address the TODO.
Would you like assistance in translating and resolving this TODO? I can help update the comment and suggest possible implementations.
libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration.service.ts (2)
613-619: Simplify the Return Statement
Since child has been verified to be non-null, the conditional check in the return statement is redundant.
Simplify the return statement:
-return (
- child && {
- nationalId: child.nationalId,
- fullName: child.name,
- }
-)
+return {
+ nationalId: child.nationalId,
+ fullName: child.name,
+}625-627: Use Built-in Type Guard for Filtering
While the current filter works, you can use the built-in Boolean constructor for cleaner code.
Apply this diff to simplify the filter:
-const filteredChildren = children.filter(
- (child): child is ChildInformation => child != null,
-)
+const filteredChildren = children.filter(Boolean) as ChildInformation[]This approach reduces complexity and improves readability.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
libs/application/templates/social-insurance-administration/death-benefits/src/assets/death-benefits-flow-chart.pngis excluded by!**/*.png
📒 Files selected for processing (48)
- libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration-utils.ts (2 hunks)
- libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration.service.ts (8 hunks)
- libs/application/template-loader/src/lib/templateLoaders.ts (1 hunks)
- libs/application/templates/social-insurance-administration/core/src/lib/messages.ts (2 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/.babelrc (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/.eslintrc.json (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/README.md (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/jest.config.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/project.json (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/assets/death-benefits-flow-chart.drawio (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/dataProviders/index.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/ChildrenTable.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/index.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Attachments.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/BaseInformation.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Children.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Comment.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/DeceasedSpouse.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/ExpectingChild.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/PaymentInformation.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/props.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/fields/index.tsx (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/forms/AdditionalDocumentsRequired.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/forms/InReview.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/forms/Prerequisites.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/index.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.spec.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/lib/constants.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/lib/dataSchema.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/lib/deathBenefitsUtils.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/src/types.ts (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/tsconfig.json (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/tsconfig.lib.json (1 hunks)
- libs/application/templates/social-insurance-administration/death-benefits/tsconfig.spec.json (1 hunks)
- libs/application/templates/social-insurance-administration/pension-supplement/src/forms/Prerequisites.ts (1 hunks)
- libs/application/types/src/lib/ApplicationTypes.ts (2 hunks)
- libs/application/types/src/lib/InstitutionMapper.ts (1 hunks)
- libs/clients/social-insurance-administration/src/clientConfig.json (7 hunks)
- libs/clients/social-insurance-administration/src/lib/apiProvider.ts (2 hunks)
- libs/clients/social-insurance-administration/src/lib/dto/application.dto.ts (2 hunks)
- libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.service.ts (4 hunks)
- libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.type.ts (5 hunks)
- libs/feature-flags/src/lib/features.ts (1 hunks)
- tsconfig.base.json (1 hunks)
✅ Files skipped from review due to trivial changes (8)
- libs/application/templates/social-insurance-administration/death-benefits/.babelrc
- libs/application/templates/social-insurance-administration/death-benefits/.eslintrc.json
- libs/application/templates/social-insurance-administration/death-benefits/jest.config.ts
- libs/application/templates/social-insurance-administration/death-benefits/project.json
- libs/application/templates/social-insurance-administration/death-benefits/src/assets/death-benefits-flow-chart.drawio
- libs/application/templates/social-insurance-administration/death-benefits/tsconfig.json
- libs/application/templates/social-insurance-administration/death-benefits/tsconfig.lib.json
- libs/application/templates/social-insurance-administration/death-benefits/tsconfig.spec.json
🧰 Additional context used
📓 Path-based instructions (39)
libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration-utils.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."
libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration.service.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."
libs/application/template-loader/src/lib/templateLoaders.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."
libs/application/templates/social-insurance-administration/core/src/lib/messages.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."
libs/application/templates/social-insurance-administration/death-benefits/README.md (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."
libs/application/templates/social-insurance-administration/death-benefits/src/dataProviders/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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/ChildrenTable.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/index.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Attachments.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/BaseInformation.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Children.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Comment.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/DeceasedSpouse.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/ExpectingChild.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/PaymentInformation.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/props.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."
libs/application/templates/social-insurance-administration/death-benefits/src/fields/index.tsx (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."
libs/application/templates/social-insurance-administration/death-benefits/src/forms/AdditionalDocumentsRequired.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."
libs/application/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.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."
libs/application/templates/social-insurance-administration/death-benefits/src/forms/InReview.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."
libs/application/templates/social-insurance-administration/death-benefits/src/forms/Prerequisites.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."
libs/application/templates/social-insurance-administration/death-benefits/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."
libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.spec.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."
libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.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."
libs/application/templates/social-insurance-administration/death-benefits/src/lib/constants.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."
libs/application/templates/social-insurance-administration/death-benefits/src/lib/dataSchema.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."
libs/application/templates/social-insurance-administration/death-benefits/src/lib/deathBenefitsUtils.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."
libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.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."
libs/application/templates/social-insurance-administration/death-benefits/src/types.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."
libs/application/templates/social-insurance-administration/pension-supplement/src/forms/Prerequisites.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."
libs/application/types/src/lib/ApplicationTypes.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."
libs/application/types/src/lib/InstitutionMapper.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."
libs/clients/social-insurance-administration/src/clientConfig.json (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."
libs/clients/social-insurance-administration/src/lib/apiProvider.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."
libs/clients/social-insurance-administration/src/lib/dto/application.dto.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."
libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.service.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."
libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.type.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."
libs/feature-flags/src/lib/features.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."
🪛 LanguageTool
libs/application/templates/social-insurance-administration/death-benefits/README.md
[uncategorized] ~15-~15: Possible missing comma found.
Context: ...be a guard into the actual application. Here the applicant reads general information...
(AI_HYDRA_LEO_MISSING_COMMA)
[style] ~15-~15: ‘make an application’ might be wordy. Consider a shorter alternative.
Context: ...hey cannot advance to the next step and make an application. #### Draft Valid applicant will be a...
(EN_WORDINESS_PREMIUM_MAKE_AN_APPLICATION)
[typographical] ~23-~23: It appears that a comma is missing.
Context: ...e application is in this state. In this state the application can be edited. #### Tr...
(DURING_THAT_TIME_COMMA)
[typographical] ~27-~27: It appears that a comma is missing.
Context: ...tart to review the application. In this state the application cannot be edited. ####...
(DURING_THAT_TIME_COMMA)
[uncategorized] ~31-~31: Use a comma before ‘so’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...application they can make a state change so the applicant can add any missing docum...
(COMMA_COMPOUND_SENTENCE_2)
[uncategorized] ~48-~48: Do not mix variants of the same word (‘localization’ and ‘localisation’) within a single text.
Context: ...date Contentful, see message extraction. ## Setu...
(EN_WORD_COHERENCY)
🪛 Biome
libs/application/templates/social-insurance-administration/death-benefits/src/lib/dataSchema.ts
[error] 18-18: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (58)
libs/application/templates/social-insurance-administration/death-benefits/src/fields/index.tsx (1)
1-2: LGTM! The exports follow best practices.
The named exports facilitate proper tree-shaking and module organization.
Let's verify the TypeScript types in the source files:
✅ Verification successful
TypeScript types are properly implemented in both components
Both exported components follow TypeScript best practices:
- The
Childrencomponent is properly typed asFC<FieldBaseProps> - The
Reviewcomponent has a well-definedReviewScreenPropsinterface and is typed asFC<ReviewScreenProps>
The barrel file exports are clean and the components maintain proper type safety through the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if Review and Children components have proper TypeScript types
# Expected: Find type definitions for props in both components
echo "Checking Review component types:"
ast-grep --pattern 'interface $name {
$$$
}' Review.tsx
echo "Checking Children component types:"
ast-grep --pattern 'interface $name {
$$$
}' Children.tsx
Length of output: 393
Script:
#!/bin/bash
# Let's first find the correct paths to these files
echo "Finding Review and Children component files:"
fd -e tsx -e ts "Review|Children" libs/application/templates/social-insurance-administration/death-benefits/src/fields
# Then let's check their content for TypeScript types
echo -e "\nChecking TypeScript types in found files:"
for file in $(fd -e tsx -e ts "Review|Children" libs/application/templates/social-insurance-administration/death-benefits/src/fields); do
echo -e "\nFile: $file"
ast-grep --pattern 'interface $name {
$$$
}' "$file"
# Also check for type aliases
ast-grep --pattern 'type $name = {
$$$
}' "$file"
done
Length of output: 2127
Script:
#!/bin/bash
# Let's check the actual content of these files and their parent directories
echo "Checking Children directory structure:"
ls -R libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/
echo -e "\nChecking Review directory structure:"
ls -R libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/
echo -e "\nChecking Children component implementation:"
cat libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx
echo -e "\nChecking Review component implementation:"
cat libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/index.tsx
Length of output: 6737
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/props.ts (1)
3-9: Well-structured TypeScript interface with proper type definitions.
The ReviewGroupProps interface is well-designed with:
- Clear and descriptive property names
- Proper TypeScript type definitions
- Good separation of concerns between data (
application), state (editable), and behaviors (groupHasNoErrors,hasError,goToScreen)
libs/application/templates/social-insurance-administration/death-benefits/src/types.ts (1)
1-1: LGTM! Good reuse of core types
The import statement correctly reuses types from the core module, promoting code consistency across the application.
libs/application/templates/social-insurance-administration/death-benefits/src/index.ts (1)
3-4: Consider adding error boundaries for dynamic imports.
The dynamic imports are good for code splitting, but the consuming components should be prepared to handle loading failures.
Run this check to verify error handling in consumer components:
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx (2)
1-4: LGTM! Well-structured imports following best practices.
The imports are properly typed and utilize shared components from the design system, promoting reusability across applications.
14-14: LGTM! Export follows best practices.
The default export is appropriate for a single component file and supports effective tree-shaking.
libs/application/templates/social-insurance-administration/death-benefits/src/lib/constants.ts (2)
1-3: LGTM! Well-structured imports.
The imports are properly typed and follow good practices by:
- Utilizing named imports for better tree-shaking
- Reusing messages from the core module
5-12: 🛠️ Refactor suggestion
Consider adding type safety for attachment keys.
While the current implementation is type-safe for values, consider creating a union type for the keys to prevent typos and ensure consistency across the application.
+export type AttachmentLabelKey = 'additionalDocuments' | 'expectingChild' | 'deathCertificate'
+
export const AttachmentLabel: {
- [key: string]: MessageDescriptor
+ [key in AttachmentLabelKey]: MessageDescriptor
} = {
additionalDocuments:
socialInsuranceAdministrationMessage.confirm.additionalDocumentsAttachment,
expectingChild: deathBenefitsFormMessage.confirm.expectingChildAttachment,
deathCertificate: deathBenefitsFormMessage.confirm.deathCertificateAttachment,
}Additionally, please ensure that the handling of sensitive documents (like death certificates) follows security best practices throughout the application.
libs/application/templates/social-insurance-administration/death-benefits/src/forms/InReview.ts (1)
1-9: LGTM: Imports are tree-shaking friendly
The imports are well-structured using named imports which enables effective tree-shaking during bundling.
libs/clients/social-insurance-administration/src/lib/dto/application.dto.ts (1)
9-9: LGTM: Clean import addition
The SpouseTaxCardUsage type import is properly structured and follows TypeScript best practices.
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/ExpectingChild.tsx (2)
1-36: Well-structured component with good practices
The component follows React best practices, properly implements localization, and uses shared UI components effectively. It's well-integrated with the island.is design system and maintains consistency with other review components.
8-12: 🛠️ Refactor suggestion
Enhance type safety with explicit application type
The application prop type should be explicitly defined to ensure type safety across the application.
+import { Application } from '@island.is/application/core'
export const ExpectingChild = ({
application,
editable,
goToScreen,
-}: ReviewGroupProps) => {
+}: ReviewGroupProps & { application: Application }) => {Likely invalid or redundant comment.
libs/application/templates/social-insurance-administration/death-benefits/src/dataProviders/index.ts (2)
1-7: LGTM! Clean imports and relevant re-exports.
The imports and re-exports are well-organized and follow TypeScript best practices. The re-exported APIs are necessary for handling user information in death benefits applications.
9-38: LGTM! Well-structured API definitions. Verify integration points.
The API definitions are consistently structured and properly segregated by functionality. Let's verify their integration with the application template.
✅ Verification successful
Let me verify the actual usage of these APIs in the death benefits template to ensure proper integration.
Based on the verification results, I can now provide a final response:
API definitions are properly integrated and consistently used
The verification shows that:
- The APIs are properly imported and used across multiple social insurance administration templates
- The namespace 'SocialInsuranceAdministration' is consistently used across all related templates
- The APIs are properly structured in the template's dependency chain
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the integration of these APIs within the application template
# Test: Check if these APIs are properly imported and used in the application template
echo "Checking API usage in application template..."
rg -l "SocialInsuranceAdministration.*Api" --type ts
# Test: Verify the namespace consistency
echo "Verifying namespace consistency..."
rg "namespace: 'SocialInsuranceAdministration'" --type ts
Length of output: 6380
Script:
#!/bin/bash
# Check how these APIs are used in the death benefits template
rg -A 2 "SocialInsuranceAdministration.*Api" libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts
# Check if there are any type definitions for these APIs
rg "interface.*SocialInsuranceAdministration" --type ts
Length of output: 795
Script:
#!/bin/bash
# Check the actual implementation of the template to see how these APIs are used
rg -B 2 -A 5 "externalData.*SocialInsuranceAdministration" libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts
# Check if there are any type definitions in the client implementation
rg -B 2 -A 5 "type|interface" libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.config.ts
Length of output: 298
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Children/ChildrenTable.tsx (3)
1-13: LGTM! Well-structured imports and type definitions.
The code demonstrates good practices with:
- Named imports for optimal tree-shaking
- Proper TypeScript interface definition
- Clear dependency management
48-48: LGTM! Clean export statement.
The default export is appropriate for a single component file.
14-16: 🛠️ Refactor suggestion
Consider handling loading states.
The component immediately uses external data but doesn't handle the loading state while data is being fetched.
Consider adding loading state handling:
const ChildrenTable: FC<ChildrenTableProps> = ({ application }) => {
const { formatMessage } = useLocale()
+ const [isLoading, setIsLoading] = useState(true)
const { children } = getApplicationExternalData(application.externalData)libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/Children.tsx (2)
1-8: LGTM! Well-structured imports following best practices.
The imports are properly organized, using specific imports that enable effective tree-shaking. Good use of shared UI components from the application library.
10-12: 🛠️ Refactor suggestion
Consider adding error handling for external data extraction.
While the code works, it might be vulnerable to runtime errors if the external data is undefined or malformed. Consider adding proper error handling or default values.
Consider applying this defensive programming approach:
- const { children } = getApplicationExternalData(application.externalData)
+ const { children = [] } = getApplicationExternalData(application.externalData ?? {})libs/clients/social-insurance-administration/src/lib/apiProvider.ts (2)
16-16: LGTM: Import follows established patterns
The import is correctly placed and maintains consistency with existing imports from the generated client.
71-75: Verify if write permissions are needed for death benefits
While the configuration follows the established pattern, consider the following regarding permissions:
- The scope only includes read permissions (
@tr.is/danarbaetur:read) - Other application-related APIs (e.g., ApplicationWriteApi) include write scopes
- Given this is for a new application submission, write permissions might be necessary
libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.type.ts (2)
107-108: LGTM! Document types follow the established pattern.
The new document types are properly integrated into the enum and follow the existing naming conventions.
9-9: LGTM! Verify scope usage across the application.
The API type and scope additions follow the established patterns and TypeScript best practices.
Let's verify the scope usage:
Also applies to: 22-22, 33-33
✅ Verification successful
✅ API and scope integration verified successfully
The verification shows proper integration of the DeathBenefitsApi and scope '@tr.is/danarbaetur:read':
- DeathBenefitsApi is correctly injected in the service constructor
- The scope is properly configured in the apiProvider configuration
- All necessary files have the required imports and implementations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the new scope is properly used in auth configurations
# and that DeathBenefitsApi is properly imported where needed
# Check scope usage in auth configs
rg -l "@tr.is/danarbaetur:read"
# Check DeathBenefitsApi usage
rg -l "DeathBenefitsApi"
Length of output: 486
Script:
#!/bin/bash
# Let's verify the implementation details to ensure proper usage
# Check how DeathBenefitsApi is used in the service
rg -A 5 "DeathBenefitsApi" libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.service.ts
# Check how the scope is configured in apiProvider
rg -A 5 "@tr.is/danarbaetur:read" libs/clients/social-insurance-administration/src/lib/apiProvider.ts
Length of output: 975
libs/application/templates/social-insurance-administration/death-benefits/src/forms/AdditionalDocumentsRequired.ts (3)
1-12: LGTM! Imports follow best practices
The imports demonstrate good practices with:
- Specific utility imports enabling effective tree-shaking
- Reuse of shared components and utilities from core modules
- Proper TypeScript type imports
1-63: Verify consistency with other file upload forms
Let's ensure this implementation follows the same patterns as other file upload forms in the system.
✅ Verification successful
Let me analyze the file upload form implementations to verify consistency.
Implementation follows consistent patterns across social insurance administration forms
The file upload implementation is consistent with other forms in the social insurance administration domain, particularly:
- Uses the shared
fileUploadSharedPropsfrom the core social insurance administration template - Follows the same pattern as other
AdditionalDocumentsRequiredforms in related modules (pension-supplement, household-supplement, old-age-pension, etc.) - Maintains consistent structure with:
- Empty title field
- Shared file upload properties
- Submit field with refetch after submit
- IN_PROGRESS form mode
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find similar file upload form implementations
ast-grep --pattern 'buildFileUploadField({
$$$
})'
# Check for other forms using the IN_PROGRESS mode
ast-grep --pattern 'mode: FormModes.IN_PROGRESS'
Length of output: 170552
Script:
#!/bin/bash
# Search for other forms using fileUploadSharedProps
rg "fileUploadSharedProps" -A 2 -B 2
# Search for other AdditionalDocumentsRequired forms
fd "AdditionalDocumentsRequired.ts"
Length of output: 27668
14-21: 🛠️ Refactor suggestion
Consider adding type definitions for form data
While the form configuration is good, consider adding TypeScript interfaces to define the expected structure of the form data for better type safety and documentation.
interface AdditionalDocumentsFormData {
fileUploadAdditionalFilesRequired: {
additionalDocumentsRequired: File[];
};
}
export const AdditionalDocumentsRequired: Form<AdditionalDocumentsFormData> = buildForm({
// ... existing configuration
})Verify accessibility requirements
Given that this is a death benefits application form, ensure it meets accessibility standards for users who might be under emotional stress.
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/BaseInformation.tsx (3)
1-12: LGTM! Well-structured imports following best practices.
The imports are properly organized, using shared components and utilities from the core libraries, which promotes reusability across NextJS apps.
1-110: Overall implementation follows best practices and guidelines.
The component is well-structured, reusable, and properly typed. It effectively uses shared UI components and follows the coding guidelines for library code. The responsive grid implementation ensures proper display across different screen sizes.
13-26: 🛠️ Refactor suggestion
Consider strengthening type safety for the goToScreen prop.
The optional chaining on goToScreen?.('applicant') suggests this prop is optional, but it's critical for the edit functionality. Consider making it required in the ReviewGroupProps type if editing should always be supported.
If editing is mandatory, consider updating the props type:
interface ReviewGroupProps {
application: Application;
editable: boolean;
goToScreen: (screen: string) => void; // Remove optional modifier
}libs/application/templates/social-insurance-administration/pension-supplement/src/forms/Prerequisites.ts (3)
Line range hint 1-124: LGTM for code structure and TypeScript usage.
The implementation follows good practices:
- Proper use of TypeScript for type safety
- Modular component composition using builder pattern
- Externalized messages for internationalization
- Clean imports supporting tree-shaking
28-28: Verify form identifier alignment with death benefits context.
The form ID PensionSupplementPrerequisites seems inconsistent with the PR's context of death benefits application. Consider whether this should be renamed to better reflect its purpose (e.g., DeathBenefitsPrerequisites).
Line range hint 94-98: Verify eligibility logic for death benefits context.
The isEligible function imported from pensionSupplementUtils needs verification to ensure it includes appropriate eligibility checks for death benefits applications (e.g., relationship to deceased, timing of application).
libs/application/templates/social-insurance-administration/death-benefits/src/forms/Prerequisites.ts (2)
1-27: LGTM! Well-structured imports following best practices.
The imports are well-organized and leverage shared components from the application core, promoting reusability across different NextJS apps.
105-126: Verify handling of sensitive information in eligibility messages.
Since this form deals with death benefits, ensure that the error messages for ineligibility don't expose sensitive personal information about the deceased or the applicant.
✅ Verification successful
Let me check the actual content of these messages to verify if they contain any sensitive information.
Let me try a different approach to get the message content.
Let me try one more time with proper escaping of special characters.
Ineligibility messages are appropriately generic and secure
The ineligibility message content has been reviewed and contains only general eligibility criteria without exposing any sensitive personal information. The message:
- Lists only standard eligibility rules (domicile status, age, marital status)
- Doesn't include specific details about the deceased or applicant
- Provides a generic contact email for questions
- Uses appropriate language considering the sensitive nature of death benefits
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for message definitions to verify content sensitivity
rg -A 2 "isNotEligibleDescription" --type ts
Length of output: 4581
Script:
#!/bin/bash
# Get the actual message content for death benefits
ast-grep --pattern 'isNotEligibleDescription: {
$$$
defaultMessage: $MSG
$$$
}' libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts
Length of output: 181
Script:
#!/bin/bash
# Get the content around the message definition using ripgrep
rg -B 2 -A 4 "isNotEligibleDescription: {" libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts
Length of output: 256
Script:
#!/bin/bash
# Get the content of the messages file
cat libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts
Length of output: 9749
libs/clients/social-insurance-administration/src/lib/socialInsuranceAdministrationClient.service.ts (3)
11-11: LGTM: Proper TypeScript imports and type definitions.
The new imports follow TypeScript best practices with explicit type imports, promoting type safety and effective tree-shaking.
Also applies to: 18-18
33-33: LGTM: Proper dependency injection.
The DeathBenefitsApi is correctly injected following the established pattern, with appropriate access modifiers and immutability.
52-54: LGTM: Consistent auth middleware implementation.
The authentication middleware setup follows the established pattern, maintaining consistency with other API auth wrappers in the service.
libs/feature-flags/src/lib/features.ts (1)
42-42: LGTM! Well-integrated feature flag.
The new feature flag follows the established patterns and properly supports the death benefits application feature. The enum export ensures type safety across the application.
libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.spec.ts (1)
34-188: 🛠️ Refactor suggestion
Improve test organization and coverage.
Several improvements could enhance the test suite:
- The multiple
describe('state transitions', ...)blocks should be consolidated into a single block with nested describes for better organization. - Common test data could be extracted to reduce duplication.
- Missing test coverage for invalid state transitions and unchanged states.
Here's a suggested restructure for better organization:
describe('Death Benefits Template', () => {
describe('state transitions', () => {
describe('from draft state', () => {
it('should transition to tryggingastofnunSubmitted on submit', () => {
// existing test
})
it('should transition to tryggingastofnunSubmitted on abort', () => {
// existing test
})
it('should not transition on invalid events', () => {
// new test
})
})
describe('from tryggingastofnunSubmitted state', () => {
// Group related tests
})
// ... other state groups
})
})Let's verify the test coverage:
libs/application/templates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/PaymentInformation.tsx (1)
1-20: LGTM! Well-organized imports with proper TypeScript support.
The imports are properly structured, utilizing the shared island.is components and utilities, which promotes reusability across the application.
libs/application/templates/social-insurance-administration/death-benefits/src/lib/messages.ts (2)
1-3: LGTM! Well-structured type definition.
The type definition is clear and promotes reusability across different components.
172-183: LGTM! Clear and consistent state messages.
The state messages are well-structured and provide clear feedback for application status.
libs/application/types/src/lib/ApplicationTypes.ts (2)
66-66: LGTM! Enum value follows conventions.
The new DEATH_BENEFITS enum value follows the established naming pattern and maintains alphabetical ordering.
342-345: LGTM! Configuration follows the established pattern.
The configuration for death benefits follows the standard structure and reuses common translation namespaces, maintaining consistency with other social insurance applications.
libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration-utils.ts (3)
37-41: LGTM: Imports follow established patterns
The new imports maintain consistency with other benefit types in the module and are properly scoped to the death benefits functionality.
384-387: 🛠️ Refactor suggestion
Add null safety and consider moving to shared utilities
The function is well-focused but could be more robust and reusable.
-export const getChildrenNationalIds = (
- children: ChildInformation[],
-): string[] => children.map(({ nationalId }) => nationalId)
+export const getChildrenNationalIds = (
+ children?: ChildInformation[] | null,
+): string[] => children?.map(({ nationalId }) => nationalId) ?? []Consider moving this utility to a shared location since it could be useful for other benefit types that deal with children's information.
Let's check if there are other places using similar functionality:
307-376: 🛠️ Refactor suggestion
Consider adding input validation
The function should validate required fields before constructing the DTO to prevent runtime errors.
Let's check if there are any validation utilities in use:
Consider adding validation:
function validateDeathBenefitsInput(answers: any): void {
if (!answers.deceasedSpouseNationalId) {
throw new Error('Deceased spouse national ID is required')
}
// Add other validations as needed
}libs/application/types/src/lib/InstitutionMapper.ts (1)
327-330: Institution mapping looks good.
The mapping of death benefits application to Tryggingastofnun (Social Insurance Administration) is correct, as this institution handles social insurance benefits including death-related benefits.
Let's verify the institution mapping is used correctly in the codebase:
✅ Verification successful
Institution mapping for death benefits is correctly implemented and used
The verification confirms that the death benefits application is properly integrated with Tryggingastofnun (Social Insurance Administration):
- The template is correctly placed under social-insurance-administration directory
- The application is processed by the social insurance administration service
- The template loader properly imports the death benefits template from the social-insurance-administration path
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the death benefits application correctly uses this institution mapping
# Test: Search for death benefits application usage of institution data
rg -A 5 "ApplicationTypes.DEATH_BENEFITS.*institution"
Length of output: 56
Script:
#!/bin/bash
# Let's try a broader search for death benefits usage
rg -l "ApplicationTypes.DEATH_BENEFITS"
# Then search for institution mapping usage
rg -l "InstitutionMapper"
# Check how the institution mapper is used with applications
ast-grep --pattern 'InstitutionMapper.$$$($$$ApplicationTypes.$$$)'
Length of output: 692
Script:
#!/bin/bash
# Let's check how death benefits template uses the institution information
rg -A 5 "DeathBenefitsTemplate" libs/application/templates/social-insurance-administration/death-benefits/src/lib/DeathBenefitsTemplate.ts
# Check the social insurance administration service implementation
rg -A 5 "DEATH_BENEFITS" libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration.service.ts
# Check how the template loader handles death benefits
rg -A 5 "DEATH_BENEFITS" libs/application/template-loader/src/lib/templateLoaders.ts
Length of output: 1571
libs/application/templates/social-insurance-administration/core/src/lib/messages.ts (1)
387-393: LGTM! Message descriptor implementation follows best practices.
The implementation correctly uses TypeScript and follows the established pattern for message descriptors, making it reusable across different NextJS apps.
tsconfig.base.json (1)
501-503: LGTM! Path mapping follows established patterns.
The new path mapping for the death benefits template is correctly structured and follows the established pattern for social insurance administration templates.
libs/application/templates/social-insurance-administration/death-benefits/src/lib/dataSchema.ts (1)
174-174: TypeScript usage aligns with best practices
Exporting SchemaFormValues using z.infer<typeof dataSchema> leverages TypeScript's type inference, ensuring type safety and consistency across the application.
libs/application/template-api-modules/src/lib/modules/templates/social-insurance-administration/social-insurance-administration.service.ts (6)
22-26: Imports for Death Benefits Module are Correct and Necessary
The new imports for handling death benefits applications are appropriate and correctly implemented.
40-40: Import Statement for Transformer Function Added
The import of transformApplicationToDeathBenefitsDTO is necessary for transforming the application data and is correctly added.
58-58: Dependency Injection of National Registry Service Confirmed
The nationalRegistryApi is correctly injected into the service constructor, enhancing the service's ability to access national registry data.
521-535: Ensure Consistent Use of Application Type IDs
In the sendApplication method, the handling of DEATH_BENEFITS is consistent with other application types, and the application data is correctly transformed and sent.
631-633: Spousal Information Retrieval Implemented Correctly
The getSpousalInfo method correctly interfaces with the siaClientService to retrieve spousal information.
115-119:
Syntax Error in Conditional Statement
There's a syntax error at line 115~ where the if statement ends with a colon : instead of an opening brace {. This is invalid syntax in TypeScript/JavaScript.
Apply this diff to correct the syntax:
-if (application.typeId === ApplicationTypes.DEATH_BENEFITS):
+if (application.typeId === ApplicationTypes.DEATH_BENEFITS) {Also, ensure that the closing brace } is properly aligned with the opening brace.
Likely invalid or redundant comment.
libs/application/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.ts (1)
352-377: Ensure external data provides deceased spouse information
The fields for the deceased spouse's information have readOnly: true and rely on external data. If the external data does not include these details, the fields might appear empty to the user without the ability to edit them.
Please verify that deceasedSpouseNationalId, deceasedSpouseDateOfDeath, and deceasedSpouseName are always provided in the external data. If not, consider adding error handling or default values.
If there's a possibility that the data might be missing, you may need to handle this scenario to prevent empty read-only fields from confusing the user.
✅ Verification successful
Let me gather more information about how the external data is handled.
Let me search for the condition that controls when these fields are shown and any validation logic.
Let me try a different search pattern to find the validation and data fetching logic.
From analyzing the code, I can now provide a final response:
External data fields are properly guarded against missing data
The deceased spouse information fields are only displayed when the data exists, as evidenced by the condition:
condition: (_, externalData) =>
!!getApplicationExternalData(externalData)
.deceasedSpouseNationalId,This condition ensures the fields are only shown when the deceased spouse's national ID exists in the external data. The read-only fields are therefore appropriately protected and won't appear empty to users.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that deceased spouse data is present in all relevant cases
# Check if the external data includes the required fields
echo "Checking for deceased spouse data in external data..."
# Since actual data cannot be fetched, ensure your data fetching logic handles missing data appropriately
Length of output: 116
Script:
#!/bin/bash
# Search for getApplicationExternalData implementation
ast-grep --pattern 'function getApplicationExternalData'
# Search for any type definitions or interfaces related to external data
rg -g '*.ts' -g '*.tsx' 'interface.*ExternalData|type.*ExternalData' -A 5
# Search for any validation or error handling related to these fields
rg -g '*.ts' -g '*.tsx' 'deceasedSpouse(NationalId|DateOfDeath|Name)' -B 2 -A 2
Length of output: 24740
Script:
#!/bin/bash
# Search for the condition that controls when deceased spouse fields are shown
rg -g '*.ts' -g '*.tsx' 'condition.*deceasedSpouse' -B 2 -A 2
# Search for getApplicationExternalData implementation specifically in death benefits
rg -g '*.ts' -g '*.tsx' 'getApplicationExternalData.*socialInsuranceAdministrationSpousalInfo' -B 2 -A 2
# Look for any error handling or validation related to these fields
ast-grep --pattern 'if ($$$deceasedSpouse$$$) {
$$$
}'
Length of output: 229
Script:
#!/bin/bash
# Search for the section where these fields are defined and any surrounding conditions
rg -g '*.ts' -g '*.tsx' 'deceasedSpouseInfo' -B 10 -A 10
# Look for any error handling or data presence checks
rg -g '*.ts' -g '*.tsx' 'socialInsuranceAdministrationSpousalInfo' -B 5 -A 5
# Search for any data provider or external data fetching setup
ast-grep --pattern 'buildExternalDataProvider({
$$$
title: $_,
$$$
})'
Length of output: 391852
...ates/social-insurance-administration/death-benefits/src/fields/Review/review-groups/props.ts
Show resolved
Hide resolved
libs/application/templates/social-insurance-administration/death-benefits/src/types.ts
Show resolved
Hide resolved
libs/application/templates/social-insurance-administration/death-benefits/src/index.ts
Show resolved
Hide resolved
...ation/templates/social-insurance-administration/death-benefits/src/fields/Children/index.tsx
Show resolved
Hide resolved
libs/application/templates/social-insurance-administration/death-benefits/src/lib/constants.ts
Outdated
Show resolved
Hide resolved
...modules/templates/social-insurance-administration/social-insurance-administration.service.ts
Outdated
Show resolved
Hide resolved
...tion/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.ts
Show resolved
Hide resolved
...tion/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.ts
Show resolved
Hide resolved
...tion/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.ts
Outdated
Show resolved
Hide resolved
...tion/templates/social-insurance-administration/death-benefits/src/forms/DeathBenefitsForm.ts
Outdated
Show resolved
Hide resolved
…th-benefits/src/forms/DeathBenefitsForm.ts Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Datadog ReportAll test runs ❌ 70 Total Test Services: 1 Failed, 66 Passed Test ServicesThis report shows up to 10 services
❌ Failed Tests (2)
🔻 Code Coverage Decreases vs Default Branch (2) |
…th-benefits/src/forms/DeathBenefitsForm.ts Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…s/island.is into feat/survivors-benefits
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
Affected services are: air-discount-scheme-api,air-discount-scheme-backend,api,application-system-api,download-service,financial-aid-api,financial-aid-backend,financial-aid-open-api,judicial-system-api,judicial-system-digital-mailbox-api,judicial-system-backend,judicial-system-message-handler,judicial-system-robot-api,judicial-system-scheduler,judicial-system-xrd-api,license-api,regulations-admin-backend,services-auth-admin-api,services-auth-ids-api,services-auth-delegation-api,services-auth-personal-representative,services-auth-personal-representative-public,services-auth-public-api,services-endorsements-api,services-search-indexer,services-sessions,services-university-gateway,services-user-notification,services-user-profile,air-discount-scheme-web,skilavottord-web,web,application-system-form,island-ui-storybook,portals-admin,service-portal,system-e2e, Deployed services: application-system-api,application-system-form,service-portal,service-portal-api,portals-admin,api,web,skilavottord-web,island-ui-storybook,download-service,endorsement-system-api,air-discount-scheme-web,air-discount-scheme-backend,air-discount-scheme-api,regulations-admin-backend,application-system-api-worker,license-api,services-sessions,services-sessions-worker,services-sessions-cleanup,services-university-gateway,services-university-gateway-worker,consultation-portal. |
What
New application - death benefits
http://localhost:4242/umsoknir/danarbaetur/
Why
For applicants to apply for death benefits after the loss of a spouse
/umsoknir/danarbaetur
Gervimenn
Martha ÞÍ Ferati - 0911469
Marta ÞÍ Torp - 0501489
David ÞÍ Daniels - 1001459
Screenshots
Personal information:
Bank and tax details:
Spouse info:
Expecting child screen (if cohabitation has lasted less than year - applicants get this question):
Child file upload screen:
Additional documents screen:
Additional comments:
Application overview:
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Enhancements
Bug Fixes
These updates significantly improve the user experience for applicants seeking death benefits, streamlining the application process and enhancing data management.