feat(driving-license): check if 65+ renewal is possible #16292
Conversation
WalkthroughThe pull request introduces updates to the 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: 5
🧹 Outside diff range and nitpick comments (11)
libs/application/templates/driving-license/src/lib/constants.ts (2)
29-41: LGTM! Consider consolidating license category constants.The new
codesExtendedLicenseCategoriesconstant is a welcome addition, providing a comprehensive list of extended license categories. It adheres to the coding guidelines by being exportable and using TypeScript.Consider consolidating this new constant with the existing
otherLicenseCategoriesto avoid duplication and improve maintainability. For example:export const allLicenseCategories = [ 'C1', 'C1E', 'C', 'CE', 'D1', 'D1E', 'D', 'DE', 'Bfar', 'Far', 'FAR' ]; export const otherLicenseCategories = allLicenseCategories.filter(category => ['C', 'C1', 'CE', 'D', 'D1', 'DE'].includes(category)); export const codesExtendedLicenseCategories = allLicenseCategories;This approach would make it easier to maintain the list of license categories in one place while still providing separate constants for different use cases.
42-42: LGTM! Consider adding comments for code clarity.The new
remarksCannotRenew65constant is well-named and adheres to the coding guidelines. It's exported for reusability and uses TypeScript as required.To improve code clarity, consider adding a comment explaining the meaning of each code. For example:
export const remarksCannotRenew65 = [ '400', // e.g., "Medical condition preventing renewal" '450', // e.g., "Age-related restriction" '95' // e.g., "Administrative reason" ];This would make the code more self-documenting and easier for other developers to understand and maintain.
libs/application/templates/driving-license/src/fields/EligibilitySummary/extractReasons.ts (2)
28-29: LGTM with a minor suggestion.The addition of the new case for
RequirementKey.NoExtendedDrivingLicenseis consistent with the existing structure. However, consider returning a description message instead of a title to align with the function's name and purpose.Consider changing:
- return requirementsMessages.noExtendedDrivingLicenseTitle + return requirementsMessages.noExtendedDrivingLicenseDescriptionThis would better align with the function's name
getDeniedByServiceMessageDescription.
Line range hint
1-97: Summary: Changes align well with PR objectives.The modifications in this file successfully implement the new feature for checking eligibility for driving license renewal, particularly for individuals aged 65 and older. The changes are well-integrated into the existing code structure and follow consistent patterns.
Key points:
- A new requirement key
NoExtendedDrivingLicensehas been added to handle extended driving license checks.- The changes are implemented in both
getDeniedByServiceMessageDescriptionandrequirementKeyToStepfunctions, ensuring comprehensive handling of the new requirement.- The code maintains good TypeScript practices and appears to be designed for reusability across different NextJS apps.
These changes align well with the PR objectives of implementing a feature to check eligibility for renewal of driving licenses for individuals aged 65 and older.
Consider documenting the purpose and usage of the
NoExtendedDrivingLicenserequirement key in the code or in a separate documentation file to improve maintainability and clarity for other developers.libs/application/templates/driving-license/src/forms/prerequisites/sectionApplicationFor.ts (3)
Line range hint
46-51: Consider a more appropriate fallback value for ageThe fallback value of 0 for the
agevariable might lead to unexpected behavior in age-based calculations. Consider using a value that clearly indicates an invalid or unset age, such as -1 or null.let age = getValueViaPath<number>( app.externalData, 'nationalRegistry.data.age', - ) ?? 0 + ) ?? -1 // or nullThis change would make it easier to distinguish between a valid age of 0 and an unset age value.
Line range hint
56-71: Approve fake data handling with a minor suggestionThe implementation of fake data handling is well-structured and correctly simulates different license scenarios. The placement of the
agereassignment within this block is appropriate.To improve readability, consider extracting the license type checks into a separate function:
function getFakeLicenseCategories(licenseType: string): Array<{ nr: string; validToCode: number }> { switch (licenseType) { case 'temp': return [{ nr: 'B', validToCode: 8 }]; case 'full': return [{ nr: 'B', validToCode: 9 }]; case 'BE': return [ { nr: 'B', validToCode: 9 }, { nr: 'BE', validToCode: 9 }, ]; default: return []; } } // Usage categories = getFakeLicenseCategories(fakeData.currentLicense);This refactoring would make the code more maintainable and easier to extend in the future.
97-97: Approve simplified condition with a suggestion for consistencyThe simplification of the condition for disabling the B_FULL_RENEWAL_65 option improves code readability and correctly handles both real and fake data scenarios.
For consistency with other parts of the code and to make the age threshold more maintainable, consider extracting it as a constant:
const RENEWAL_AGE_THRESHOLD = 65; // Then use it in the condition disabled: !currentLicense || age < RENEWAL_AGE_THRESHOLD,This change would make it easier to update the age threshold in the future if needed and would align with best practices for magic number avoidance.
libs/api/domains/driving-license/src/lib/drivingLicense.service.ts (1)
358-366: LGTM! Consider using a switch statement for better readability.The changes successfully implement the new license type 'B-full-renewal-65' and handle it appropriately. The method remains reusable and adheres to TypeScript usage guidelines.
To improve code readability and maintainability, consider refactoring the if-else chain into a switch statement:
switch (type) { case 'B-full-renewal-65': return this.drivingLicenseApi.getCanApplyForRenewal65({ token, }); case 'B-full': return this.drivingLicenseApi.getCanApplyForCategoryFull({ category: 'B', token, }); case 'BE': return this.drivingLicenseApi.getCanApplyForCategoryFull({ category: 'BE', token, }); case 'B-temp': return this.drivingLicenseApi.getCanApplyForCategoryTemporary({ token, }); default: throw new Error('unhandled license type'); }This refactoring would make it easier to add new license types in the future and improve the overall structure of the method.
libs/clients/driving-license/src/lib/drivingLicenseApi.service.ts (1)
375-390: LGTM! Consider standardizing token handling for consistency.The new
getCanApplyForRenewal65method is well-implemented and follows the existing patterns in the class. It correctly uses API version constants and returns the expected result structure.For consistency with other methods in this class, consider removing the 'Bearer ' prefix from the token:
- jwttoken: params.token, + jwttoken: params.token.replace('Bearer ', ''),This change would align the token handling with methods like
getIsTeacherandgetDrivingAssessment.libs/application/templates/driving-license/src/lib/messages.ts (1)
983-992: LGTM! Consider adding more context to the description.The new messages for 65+ driving license renewal are well-formatted and consistent with the existing code. They clearly communicate that it's not possible to apply for a 65+ driving license renewal.
Consider expanding the
descriptionfield to provide more context for translators or other developers. For example:noExtendedDrivingLicenseDescription: { id: 'dl.application:requirementunmet.noExtendedDrivingLicenseDescription', defaultMessage: 'Ekki hægt að sækja um endurnýjun á 65+ ökuskírteini.', - description: 'requirement unmet 65 plus renewal', + description: 'Message shown when a user 65 or older cannot renew their driving license online', },libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (1)
Line range hint
26-26: Address the TODO regarding health certificate supportThe TODO comment indicates that this code should be removed when RLS/SGS supports the health certificate in the BE license. Please ensure this task is tracked and the code is updated accordingly.
Would you like me to open a new GitHub issue to track this task?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (9)
- libs/api/domains/driving-license/src/lib/drivingLicense.service.ts (1 hunks)
- libs/api/domains/driving-license/src/lib/drivingLicense.type.ts (1 hunks)
- libs/application/templates/driving-license/src/fields/EligibilitySummary/extractReasons.ts (2 hunks)
- libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (3 hunks)
- libs/application/templates/driving-license/src/forms/prerequisites/sectionApplicationFor.ts (4 hunks)
- libs/application/templates/driving-license/src/lib/constants.ts (1 hunks)
- libs/application/templates/driving-license/src/lib/messages.ts (1 hunks)
- libs/application/templates/driving-license/src/lib/types.ts (1 hunks)
- libs/clients/driving-license/src/lib/drivingLicenseApi.service.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
libs/api/domains/driving-license/src/lib/drivingLicense.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/api/domains/driving-license/src/lib/drivingLicense.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/application/templates/driving-license/src/fields/EligibilitySummary/extractReasons.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/driving-license/src/fields/EligibilitySummary/useEligibility.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/driving-license/src/forms/prerequisites/sectionApplicationFor.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/driving-license/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/driving-license/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/driving-license/src/lib/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/clients/driving-license/src/lib/drivingLicenseApi.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."
🔇 Additional comments (4)
libs/application/templates/driving-license/src/lib/types.ts (1)
14-14: LGTM! The change adheres to coding guidelines.The addition of the optional
issuedproperty to theDrivingLicenseCategorytype is well-implemented and aligns with TypeScript best practices. This change enhances the type definition without breaking existing usage.The file continues to meet the coding guidelines for
libs/**/*:
- The types defined are reusable across different NextJS apps dealing with driving licenses.
- TypeScript is correctly used for defining and exporting types.
- The structure allows for effective tree-shaking and bundling.
libs/application/templates/driving-license/src/fields/EligibilitySummary/extractReasons.ts (1)
90-94: LGTM! Verify message consistency.The new case for
RequirementKey.NoExtendedDrivingLicenseis well-implemented and consistent with the existing structure. Both title and description are provided as expected.To ensure consistency across the application, please verify that the messages used here (
noExtendedDrivingLicenseTitleandnoExtendedDrivingLicenseDescription) are defined in therequirementsMessagesobject. Run the following script to check:✅ Verification successful
Verified!
The new message keys
noExtendedDrivingLicenseTitleandnoExtendedDrivingLicenseDescriptionare properly defined inrequirementsMessages.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the new messages are defined in requirementsMessages # Test: Search for the new message keys in the file containing requirementsMessages rg --type typescript 'noExtendedDrivingLicenseTitle|noExtendedDrivingLicenseDescription' libs/application/templates/driving-license/src/lib/messages.tsLength of output: 188
Script:
#!/bin/bash # Description: Verify that the new messages are defined in requirementsMessages # Test: Search for the new message keys in the file containing requirementsMessages rg --type ts 'noExtendedDrivingLicenseTitle|noExtendedDrivingLicenseDescription' libs/application/templates/driving-license/src/lib/messages.tsLength of output: 373
libs/application/templates/driving-license/src/forms/prerequisites/sectionApplicationFor.ts (1)
Line range hint
1-124: Overall assessment: Improvements in age handling and fake data scenariosThe changes in this file effectively implement the feature for checking 65+ driving license renewal eligibility. The modifications improve age-based condition handling and introduce a robust fake data mechanism for testing various scenarios. The code adheres to TypeScript best practices and maintains a structure that supports reusability and effective tree-shaking.
Key improvements:
- Flexible age variable handling
- Comprehensive fake data simulation
- Simplified conditions for license type options
The suggested refactorings, if implemented, would further enhance code maintainability and readability. Great job on implementing this feature!
libs/api/domains/driving-license/src/lib/drivingLicense.service.ts (1)
358-366: LGTM! Typo in API call corrected.The correction of the API call from
postTemporaryLicenseWithHealthDeclaratiotopostTemporaryLicenseWithHealthDeclarationfixes a typo and ensures the correct method is called. This change improves code quality and reduces the risk of runtime errors.
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
Datadog ReportAll test runs ✅ 25 Total Test Services: 0 Failed, 24 Passed Test ServicesThis report shows up to 10 services
🔻 Code Coverage Decreases vs Default Branch (5) |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (1)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (1)
199-211: LGTM with a minor suggestion for type annotation.The return statement for the B_FULL_RENEWAL_65 case is well-structured and includes all necessary conditions for eligibility. The use of the nullish coalescing operator (??) is a good practice for handling potential undefined values.
To further improve type safety, consider adding an explicit type annotation to the returned object:
return { loading, eligibility: { isEligible: loading ? undefined : (data.drivingLicenseApplicationEligibility?.isEligible ?? false) && hasQualityPhoto && !hasExtendedDrivingLicense && !hasAnyInvalidRemarks, requirements, } as ApplicationEligibility, };This ensures that the returned object strictly adheres to the expected
UseEligibilityResulttype, providing better type checking and developer experience.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.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."
🔇 Additional comments (2)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (2)
3-7: LGTM: Import statements are well-organized and use TypeScript types.The addition of
ApplicationEligibilityRequirementaligns with the changes in the file. The import statements are organized and make use of TypeScript types, which adheres to the coding guidelines for reusability and TypeScript usage.
11-18: LGTM: New constants added for 65+ renewal eligibility check.The addition of
B_FULL_RENEWAL_65andremarksCannotRenew65constants aligns with the new functionality for checking eligibility for 65+ renewal. These constants are properly imported, promoting reusability across the application.
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (2)
100-115: LGTM: Well-implementedhasExtendedDrivingLicensefunctionThe
hasExtendedDrivingLicensefunction is well-structured with clear logic and good use of early returns. It correctly checks for extended driving licenses by comparing issuance dates.Consider adding a type annotation for the return value:
const hasExtendedDrivingLicense = ( currentLicense: DrivingLicense | undefined, drivingLicenseIssued: string | undefined, ): boolean => { // ... existing implementation ... }This addition would enhance type safety and code clarity.
168-212: LGTM: Well-implemented eligibility check for B_FULL_RENEWAL_65The new eligibility check for B_FULL_RENEWAL_65 is well-implemented and aligns with the PR objectives. It correctly checks for extended licenses, invalid remarks, and quality photos. The use of the spread operator for constructing the requirements array is efficient.
Consider adding error handling for potential undefined values:
const licenseB = currentLicense?.categories?.find( (license) => license.nr === 'B', ) ?? null; if (!licenseB) { console.warn('No B license found for B_FULL_RENEWAL_65 application'); // Handle this case, perhaps by returning early or setting a default value } const drivingLicenseIssued = licenseB?.issued;This addition would make the code more robust against unexpected data structures.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
- libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (4 hunks)
- libs/application/templates/driving-license/src/lib/messages.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- libs/application/templates/driving-license/src/lib/messages.ts
🧰 Additional context used
📓 Path-based instructions (1)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.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."
🔇 Additional comments (3)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (3)
3-7: LGTM: New imports and constants align with PR objectivesThe additions of
ApplicationEligibilityRequirement,RequirementKey,B_FULL_RENEWAL_65, andremarksCannotRenew65are appropriate for implementing the new 65+ license renewal eligibility check. These changes contribute to better type safety and code organization.Also applies to: 11-11, 13-13, 18-18
138-139: LGTM: Improved eligibility type and initializationThe change to
ApplicationEligibilityRequirement[]for theeligibilityvariable aligns with the new structure of the requirements array. The use of optional chaining and nullish coalescing (?.and??) improves the code's robustness by safely handling potential undefined values.
Line range hint
1-220: LGTM: Well-implemented feature for 65+ driving license renewal eligibilityThe changes in this file successfully implement the new feature for checking eligibility for 65+ driving license renewals. The additions and modifications are well-structured, maintain consistency with existing patterns, and follow TypeScript best practices. The code is readable, maintainable, and aligns well with the PR objectives.
Key improvements:
- Addition of new types and constants for better type safety and code organization.
- Implementation of
hasExtendedDrivingLicensefunction for clear and reusable logic.- Updated eligibility checks incorporating new requirements for 65+ renewals.
The changes adhere to the coding guidelines for libs, ensuring reusability across different NextJS apps and effective TypeScript usage.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (1)
100-115: LGTM: Well-implementedhasExtendedDrivingLicensefunction.The
hasExtendedDrivingLicensefunction is well-structured and correctly implements the logic for checking extended driving licenses. It properly handles edge cases and improves code modularity.Consider adding type annotations for better type safety:
const hasExtendedDrivingLicense = ( currentLicense: DrivingLicense | undefined, drivingLicenseIssued: string | undefined ): boolean => { // ... (rest of the function remains the same) }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (4 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.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."
🔇 Additional comments (4)
libs/application/templates/driving-license/src/fields/EligibilitySummary/useEligibility.ts (4)
3-7: LGTM: New imports and constants for 65+ renewal eligibility checks.The additions of
ApplicationEligibilityRequirement,RequirementKey,B_FULL_RENEWAL_65, andremarksCannotRenew65are appropriate for implementing the new eligibility checks for 65+ driving license renewals.Also applies to: 11-11, 18-18
138-139: LGTM: Improved eligibility type and initialization.The change in the
eligibilitytype toApplicationEligibilityRequirement[]and the updated initialization using optional chaining and nullish coalescing improve type safety and robustness.
Line range hint
1-218: LGTM: Excellent adherence to coding guidelines and best practices.The overall structure of the file is well-organized and follows a logical flow. The code effectively uses TypeScript for type definitions and adheres to best practices for reusability across different NextJS apps. The implementation aligns well with the provided coding guidelines.
168-212: LGTM: Well-implemented eligibility logic for B_FULL_RENEWAL_65.The new eligibility logic for
B_FULL_RENEWAL_65is well-structured and correctly implements the required checks for 65+ renewals. The dynamic construction of requirements enhances flexibility and maintainability.Consider adding error handling for potential undefined values. Run the following script to verify the usage of optional chaining throughout the file:
If the script returns any matches, consider adding optional chaining (
?.) to those property accesses to prevent potential runtime errors.
* check if 65 renewal is possible * remove console log * cleanup * coderabbit tweaks * coderabbit changes * quick fix * add type? --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* check if 65 renewal is possible * remove console log * cleanup * coderabbit tweaks * coderabbit changes * quick fix * add type? --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
…-pages (#16234) * Service portal removal. Add portals my pages * minor fixes * Fix * path fix * fix(portals-admin): locklist (#16279) * fix(portals-admin): locklist * tweak * msg id fix * tweak --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * feat(service-portal): feature flag resolver for documents (#16285) * fix: def info and alert * feat: add feature flag to resolver * fix: move ff call to seperate function --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(vehicles-bulk-mileage): Fixes after testing review (#16295) * fix: testing fixes v1 * fix: testing comments v2 * fix: better message * fix: function name * fix: duplicate loading --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * feat(tests): New @island/testing/e2e library (#16287) * Add @swc-node/register and @swc/core * Add testing/e2e library * update project.json for testing/e2e * fix import for libTestingE2e --------- Co-authored-by: Kristofer <[email protected]> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * feat(parental-leave): ApplicationRights (#15901) * feat(parental-leave): ApplicationRights Added applicationRights to parental-leave when sending application. Since we are using a new way of calculating periods * Fix days used by period calculation * Tests for new periods * rename function with proper camelCase * Refactor: Made duplicate code into a function * Make ApplicationRights nullable * refactor: function instead of duplicate code * remove console.log * error handling for period data * clientConfig nullable fix * Fixes for calculation of months. And using clamp to get correct value of daysLeft * Multiply amount of months by 30 for period calculation with month durations * Fix old calculation of endDate with months --------- Co-authored-by: hfhelgason <[email protected]> Co-authored-by: veronikasif <[email protected]> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * feat(passport-application): Updated readme (#16296) * updated readme * updated readme * chore: nx format:write update dirty files --------- Co-authored-by: andes-it <[email protected]> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(regulations-admin): date format signature, remove self affect, disclaimer text (#16288) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(regulations-admin): No diff no addition in appendix (#16293) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(web): Global alert banner - Handle null case (#16298) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(web): Change custom syslumenn pages config for header (#16299) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(j-s): Digital mailbox API (#16301) * feat(j-s): Block create subpoena on staging and dev * Update subpoena.service.ts * fix(j-s): Fix mailbox API * remove changes not meant for this branch * Update subpoena.service.ts * fix(j-s): reverting changes from other branch * Update subpoena.response.ts * Update subpoena.response.ts * Update subpoena.response.ts * Update subpoena.response.ts --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * fix(signature-collection): Fix list reviewed toggle (#16300) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * chore(scripts): Stricter shell script checking (#16242) * Set style level for shellcheck * Linting & formatting scripts * Remove _podman.sh script * Format all scripts * Add reviewdog/action-shfmt step * Configure shfmt * Merge from main * Linting * Move shfmt to before lint * Remove reviewdog * Allow external sources in shellcheck * Use Reviewdog for shellcheck * Set version for Reviewdog --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * chore(new-primary-school): Update messages namespace (#16302) Co-authored-by: veronikasif <[email protected]> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * feat(driving-license): check if 65+ renewal is possible (#16292) * check if 65 renewal is possible * remove console log * cleanup * coderabbit tweaks * coderabbit changes * quick fix * add type? --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> * feat(service-portal): default defender and has chosen fields for subpoena (#16306) * fix: def info and alert * feat: add feature flag to resolver * fix: move ff call to seperate function * feat: add default choices ans has chosen + loading states * fix: use type * fix: undefined type issue * fix: simplify check * Update service setup for my pages infra * chore: charts update dirty files * Remove from infra * undo rename --------- Co-authored-by: albinagu <[email protected]> Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> Co-authored-by: Ásdís Erna Guðmundsdóttir <[email protected]> Co-authored-by: Þorkell Máni Þorkelsson <[email protected]> Co-authored-by: Svanhildur Einarsdóttir <[email protected]> Co-authored-by: Kristofer <[email protected]> Co-authored-by: helgifr <[email protected]> Co-authored-by: hfhelgason <[email protected]> Co-authored-by: veronikasif <[email protected]> Co-authored-by: Rafn Árnason <[email protected]> Co-authored-by: andes-it <[email protected]> Co-authored-by: Rúnar Vestmann <[email protected]> Co-authored-by: mannipje <[email protected]> Co-authored-by: unakb <[email protected]> Co-authored-by: juni-haukur <[email protected]> Co-authored-by: birkirkristmunds <[email protected]> Co-authored-by: Kristján Albert <[email protected]>
https://app.asana.com/0/1204431115744096/1208446138184156
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores