chore(j-s): add a function to get indictment deadline date #17583
Conversation
WalkthroughThis pull request introduces comprehensive changes to the judicial system's appeal deadline calculation and handling. The modifications primarily focus on centralizing and standardizing the logic for determining appeal deadlines across multiple components and modules. Key changes include introducing new utility functions like Changes
Possibly related PRs
Suggested Labels
Suggested Reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
libs/judicial-system/types/src/lib/dates.ts (1)
3-4: Consider making appeal window constants configurable.These constants might need to be adjusted based on different jurisdictions or future policy changes.
Consider moving these to a configuration file or environment variables for easier maintenance.
libs/judicial-system/types/src/lib/dates.spec.ts (2)
4-14: Add edge case tests for fine appeal deadline.While the happy path is tested, consider adding tests for:
- Null/undefined baseDate
- Past dates
- Date at start vs end of day
16-26: Add edge case tests for verdict appeal deadline.Similar to fine appeal tests, consider adding edge cases:
- Leap year handling
- Month boundary transitions
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
209-216: Consider adding type safety for date handlingWhile the implementation is correct, we could improve type safety for the date handling.
- const baseDate = serviceRequired ? verdictViewDate : theCase.rulingDate + const baseDateString = serviceRequired ? verdictViewDate : theCase.rulingDate + const baseDate = baseDateString ? new Date(baseDateString) : undefined const verdictAppealDeadline = baseDate - ? getAppealDeadlineDate({ baseDate: new Date(baseDate), isFine }) + ? getAppealDeadlineDate({ baseDate, isFine }) : undefined
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts(5 hunks)apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts(6 hunks)apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx(2 hunks)apps/judicial-system/web/src/utils/utils.spec.tsx(1 hunks)apps/judicial-system/web/src/utils/utils.ts(0 hunks)libs/judicial-system/types/src/index.ts(1 hunks)libs/judicial-system/types/src/lib/dates.spec.ts(1 hunks)libs/judicial-system/types/src/lib/dates.ts(1 hunks)libs/judicial-system/types/src/lib/indictmentCase.ts(2 hunks)
💤 Files with no reviewable changes (1)
- apps/judicial-system/web/src/utils/utils.ts
🧰 Additional context used
📓 Path-based instructions (8)
apps/judicial-system/web/src/utils/utils.spec.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
libs/judicial-system/types/src/lib/dates.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
libs/judicial-system/types/src/lib/indictmentCase.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/judicial-system/types/src/lib/dates.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."
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
libs/judicial-system/types/src/index.ts (1)
Pattern libs/**/*: "Confirm that the code adheres to the following:
- Reusability of components and hooks across different NextJS apps.
- TypeScript usage for defining props and exporting types.
- Effective tree-shaking and bundling practices."
📓 Learnings (1)
apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx (1)
Learnt from: oddsson
PR: island-is/island.is#16495
File: apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx:102-103
Timestamp: 2024-11-12T15:15:11.835Z
Learning: In the TypeScript file `apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx`, within the `handleSetDate` function, the else block is intentionally kept to handle an unlikely scenario and should not be removed, even if it appears unnecessary due to prior validation checks.
🔇 Additional comments (11)
libs/judicial-system/types/src/lib/dates.ts (3)
6-6: LGTM! Well-defined utility function.The
setEndOfDayfunction is correctly typed and handles millisecond precision.
10-22: LGTM! Well-structured and type-safe implementation.The function is:
- Properly typed with TypeScript
- Uses named parameters for clarity
- Handles both fine and verdict cases
8-8: Consider timezone handling in date comparison.The
Date.now()comparison might be affected by timezone differences.Consider using a date library's comparison function or explicitly handling timezones:
-export const hasDatePassed = (deadline: Date) => Date.now() > deadline.getTime() +export const hasDatePassed = (deadline: Date) => { + const now = new Date() + return now.getTime() > deadline.getTime() +}libs/judicial-system/types/src/lib/indictmentCase.ts (1)
1-1: LGTM! Clean integration of new date utilities.Good refactoring to use the new date utilities, improving code maintainability.
Also applies to: 35-40
libs/judicial-system/types/src/index.ts (1)
105-107: LGTM! Export structure supports tree-shaking.The granular exports allow for effective tree-shaking in consuming applications.
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (3)
1-4: Clean import additions!The new utility functions for date handling are properly imported.
127-127: Good use of centralized date validation!The
hasDatePassedfunction is consistently used for date validation, improving code maintainability.Also applies to: 132-132
Line range hint
161-195: Clean refactoring of indictment info!The changes improve code readability through:
- Early return for missing ruling date
- Consistent use of the new date utility function
- Clear object property structure
apps/judicial-system/web/src/utils/utils.spec.tsx (1)
12-12: Clean removal of deprecated test dependencies!The import statement has been correctly updated to remove the reference to the deprecated
getAppealEndDatefunction.apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx (1)
143-146: Good use of the new date utility function!The appeal deadline calculation has been properly updated to use the centralized utility function.
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts (1)
346-346: Test expectations properly updated!The test cases have been correctly updated to expect appeal deadlines at the end of the day (23:59:59.999), aligning with the PR objective.
Also applies to: 386-386, 463-463, 482-482, 587-587
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts
Outdated
Show resolved
Hide resolved
Datadog ReportAll test runs ✅ 10 Total Test Services: 0 Failed, 10 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: 2
🧹 Nitpick comments (3)
libs/judicial-system/types/src/lib/dates.ts (2)
10-10: Consider adding null check for improved type safety.While the implementation is correct, consider adding a null check to handle potential undefined dates more gracefully.
-export const hasDatePassed = (deadline: Date) => Date.now() > deadline.getTime() +export const hasDatePassed = (deadline: Date | null | undefined): boolean => + deadline ? Date.now() > deadline.getTime() : false
26-29: Consider reducing code duplication with getIndictmentAppealDeadlineDate.The function could reuse logic from
getIndictmentAppealDeadlineDateto maintain consistency and reduce duplication.-export const getAppealDeadlineDate = ({ baseDate }: { baseDate: Date }) => { - const deadlineDate = addDays(baseDate, APPEAL_WINDOW_DAYS) - return setEndOfDay(deadlineDate) -} +export const getAppealDeadlineDate = ({ baseDate }: { baseDate: Date }) => + getIndictmentAppealDeadlineDate({ baseDate, isFine: true })apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
Line range hint
161-195: Consider using early return pattern more consistently.The implementation could be more concise by using the early return pattern consistently.
export const getIndictmentInfo = ( rulingDecision?: CaseIndictmentRulingDecision, rulingDate?: string, defendants?: Defendant[], eventLog?: EventLog[], ): IndictmentInfo => { + if (!rulingDate) return {} + const isFine = rulingDecision === CaseIndictmentRulingDecision.FINE const isRuling = rulingDecision === CaseIndictmentRulingDecision.RULING - - if (!rulingDate) { - return {} - }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts(6 hunks)apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx(2 hunks)libs/judicial-system/types/src/index.ts(1 hunks)libs/judicial-system/types/src/lib/dates.spec.ts(1 hunks)libs/judicial-system/types/src/lib/dates.ts(1 hunks)libs/judicial-system/types/src/lib/indictmentCase.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- libs/judicial-system/types/src/lib/indictmentCase.ts
- libs/judicial-system/types/src/index.ts
🧰 Additional context used
📓 Path-based instructions (4)
libs/judicial-system/types/src/lib/dates.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/judicial-system/types/src/lib/dates.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."
apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
📓 Learnings (1)
apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx (1)
Learnt from: oddsson
PR: island-is/island.is#16495
File: apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx:102-103
Timestamp: 2024-11-12T15:15:11.835Z
Learning: In the TypeScript file `apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx`, within the `handleSetDate` function, the else block is intentionally kept to handle an unlikely scenario and should not be removed, even if it appears unnecessary due to prior validation checks.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: prepare
🔇 Additional comments (4)
libs/judicial-system/types/src/lib/dates.ts (2)
1-8: LGTM! Well-defined constants and utility function.The appeal window constants are clearly defined, and the
setEndOfDayutility function correctly sets the time to the end of day with millisecond precision.
12-24: LGTM! Correctly implements appeal deadline calculation.The function properly:
- Selects the appropriate appeal window based on case type
- Sets the deadline to end of day, meeting the PR objective of ensuring deadlines encompass the entire day
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (2)
99-101: Previous review feedback about isFine parameter remains relevant.A past review identified that the
isFineparameter should be determined based on case type or ruling decision.
127-132: LGTM! Proper date validation implementation.The code correctly uses the new
hasDatePassedutility to validate dates.
apps/judicial-system/web/src/components/BlueBoxWithIcon/BlueBoxWithDate.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/judicial-system/api/src/app/modules/case/models/case.model.ts (2)
355-358: Enhance the field description with format details.The description should specify the date format and timezone to ensure consistent interpretation across the application.
@Field(() => String, { nullable: true, - description: 'appeal deadline in R cases', + description: 'Appeal deadline in R cases (ISO 8601 format in UTC, e.g., YYYY-MM-DDT23:59:59Z)', })
436-439: Enhance the field description with format details.The description should specify the date format and timezone to ensure consistent interpretation across the application.
@Field(() => String, { nullable: true, - description: 'appeal deadline for public prosecutor', + description: 'Appeal deadline for public prosecutor (ISO 8601 format in UTC, e.g., YYYY-MM-DDT23:59:59Z)', })
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/judicial-system/api/src/app/modules/case/models/case.model.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
apps/judicial-system/api/src/app/modules/case/models/case.model.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: prepare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
libs/judicial-system/types/src/lib/dates.spec.ts (3)
7-31: Add edge cases to strengthen test coverage.While the current tests are well-structured using the AAA pattern, consider adding these edge cases:
- Month transitions (e.g., Jan 31 → Feb)
- Year transitions (e.g., Dec 31 → Jan)
- Non-leap years for February dates
test('should handle month transition correctly', () => { const baseDate = new Date(2024, 0, 31) // Jan 31 const isFine = false const actualDate = getIndictmentAppealDeadlineDate({ baseDate, isFine }) expect(actualDate).toStrictEqual(new Date(2024, 1, 28, 23, 59, 59, 999)) }) test('should handle year transition correctly', () => { const baseDate = new Date(2024, 11, 31) // Dec 31 const isFine = true const actualDate = getIndictmentAppealDeadlineDate({ baseDate, isFine }) expect(actualDate).toStrictEqual(new Date(2025, 0, 3, 23, 59, 59, 999)) })
33-44: Add similar edge cases for getAppealDeadlineDate.The test suite would benefit from the same edge cases as suggested for
getIndictmentAppealDeadlineDate.test('should handle month transition correctly', () => { const baseDate = new Date(2024, 0, 31) // Jan 31 const actualDate = getAppealDeadlineDate({ baseDate }) expect(actualDate).toStrictEqual(new Date(2024, 1, 3, 23, 59, 59, 999)) }) test('should handle year transition correctly', () => { const baseDate = new Date(2024, 11, 31) // Dec 31 const actualDate = getAppealDeadlineDate({ baseDate }) expect(actualDate).toStrictEqual(new Date(2025, 0, 3, 23, 59, 59, 999)) })
46-67: Add edge cases for same-day comparison and timezone handling.The current tests cover basic past/future scenarios, but consider adding:
- Same-day comparison at different times
- Timezone edge cases
test('should handle same-day comparison correctly', () => { const mockNow = new Date(2024, 0, 1, 12, 0) // noon const sameDay = new Date(2024, 0, 1, 23, 59) // end of day jest.useFakeTimers().setSystemTime(mockNow) expect(hasDatePassed(sameDay)).toBe(false) }) test('should handle timezone transitions correctly', () => { // Mock a specific timezone for consistent testing const mockDate = new Date('2024-01-01T00:00:00Z') // UTC midnight const dateToCheck = new Date('2024-01-01T23:59:59Z') // UTC end of day jest.useFakeTimers().setSystemTime(mockDate) expect(hasDatePassed(dateToCheck)).toBe(false) })
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
libs/judicial-system/types/src/lib/dates.spec.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
libs/judicial-system/types/src/lib/dates.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."
🔇 Additional comments (2)
libs/judicial-system/types/src/lib/dates.spec.ts (2)
1-6: LGTM! Clean and focused imports.The imports are well-organized and only include the necessary functions being tested.
1-67: Well-structured test suite that aligns with requirements!The implementation effectively validates that:
- Appeal deadlines are correctly set to end of day (23:59:59.999)
- TypeScript types are properly used
- Functions are reusable across the codebase
The test structure follows best practices with clear arrange-act-assert patterns.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts(15 hunks)apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts(6 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts
🧰 Additional context used
📓 Path-based instructions (1)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (6)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (6)
1-5: LGTM! Good job centralizing the deadline calculation logic.The imported utility functions help standardize deadline calculations across the codebase, improving maintainability.
99-102: LGTM! Standardized appeal deadline calculation.The use of
getAppealDeadlineDateensures consistent deadline calculation across the codebase.
130-136: LGTM! Consistent date comparison logic.Good use of the
hasDatePassedutility function for standardized date comparisons.
168-171: LGTM! Standardized indictment appeal deadline calculation.Good use of
getIndictmentAppealDeadlineDatewith proper parameters.
193-198: LGTM! Clean and clear return structure.The direct object return improves code readability.
212-218: LGTM! Consistent deadline handling for defendants.Good use of utility functions for standardized deadline calculations and date comparisons.
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
99-101:⚠️ Potential issueAdd missing
isFineparameter to getAppealDeadlineDate call.The appeal deadline calculation might be incorrect as it's missing the
isFineparameter which determines the deadline period.appealInfo.appealDeadline = getAppealDeadlineDate({ baseDate: theRulingDate, + isFine: theCase.type === 'FINE' || theCase.indictmentRulingDecision === 'FINE', }).toISOString()
🧹 Nitpick comments (2)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (2)
Line range hint
161-195: Enhance type safety for indictment info.While the implementation is correct, consider adding runtime type checks for the optional parameters to improve type safety.
export const getIndictmentInfo = ( rulingDecision?: CaseIndictmentRulingDecision, rulingDate?: string, defendants?: Defendant[], eventLog?: EventLog[], ): IndictmentInfo => { + if (rulingDate && !Date.parse(rulingDate)) { + throw new Error('Invalid ruling date format') + } // ... rest of the implementation }
209-219: Add error handling for invalid dates in verdict appeal deadline calculation.Consider adding error handling for invalid date values to prevent runtime errors.
const baseDate = serviceRequired ? verdictViewDate : theCase.rulingDate + if (baseDate && !Date.parse(baseDate)) { + throw new Error('Invalid base date for verdict appeal deadline calculation') + } const verdictAppealDeadline = baseDate ? getIndictmentAppealDeadlineDate({ baseDate: new Date(baseDate), isFine, }) : undefined
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts(15 hunks)apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts(6 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts
🧰 Additional context used
📓 Path-based instructions (1)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (2)
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.ts (2)
1-5: LGTM! Well-structured imports.The imports follow TypeScript best practices with clear separation of concerns by importing utility functions from the types package.
127-132: LGTM! Improved date validation.Good use of the centralized
hasDatePassedutility for consistent date validation across the codebase.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #17583 +/- ##
=======================================
Coverage 35.56% 35.56%
=======================================
Files 7033 7031 -2
Lines 150624 150698 +74
Branches 43023 43020 -3
=======================================
+ Hits 53562 53600 +38
- Misses 97062 97098 +36
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 60 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts
Show resolved
Hide resolved
apps/judicial-system/api/src/app/modules/case/interceptors/case.transformer.spec.ts
Outdated
Show resolved
Hide resolved
…s/fixAppealDeadline
…island.is into j-s/fixAppealDeadline # Conflicts: # libs/judicial-system/types/src/lib/dates.ts
Datadog ReportAll test runs ✅ 9 Total Test Services: 0 Failed, 9 Passed Test Services
🔻 Code Coverage Decreases vs Default Branch (4) |
Áfrýjunarfrestur miðist við miðnætti síðasta dags
What
Why
Checklist:
Summary by CodeRabbit
New Features
Refactor
Bug Fixes
Chores