fix(j-s): Validation fix #16930
fix(j-s): Validation fix #16930
Conversation
…e-announcement-defenders
…e-announcement-defenders
…e-announcement-defenders
…d-is/island.is into j-s/service-announcement-defenders
…e-announcement-defenders
…e-announcement-defenders
WalkthroughThe changes in this pull request involve modifications to the validation logic of the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (2)
🧰 Additional context used📓 Path-based instructions (2)apps/judicial-system/backend/src/app/modules/case/dto/createCase.dto.ts (1)Pattern
apps/judicial-system/backend/src/app/modules/case/dto/updateCase.dto.ts (1)Pattern
📓 Learnings (2)apps/judicial-system/backend/src/app/modules/case/dto/createCase.dto.ts (1)apps/judicial-system/backend/src/app/modules/case/dto/updateCase.dto.ts (1)🔇 Additional comments (3)apps/judicial-system/backend/src/app/modules/case/dto/createCase.dto.ts (2)
The addition of
The validation stack for ✅ Verification successfulLet me try a different approach to verify the validation consistency between the DTOs. Validation for The validation stack for
The only difference is that the field is required in CreateCaseDto and optional in UpdateCaseDto, which is the expected behavior for update operations. 🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Verify that both DTOs have identical validation for policeCaseNumbers
# Search for policeCaseNumbers validation in both DTOs
echo "Comparing validation in CreateCaseDto and UpdateCaseDto:"
ast-grep --pattern 'readonly policeCaseNumbers!: string[]' -A 5
Length of output: 188 Script: #!/bin/bash
# Search for files containing 'CaseDto' in their names
echo "Finding relevant DTO files:"
fd "Case.*dto" --type f
# Display the content of both DTOs focusing on validation decorators
echo -e "\nChecking validation decorators in both DTOs:"
rg "@(MaxLength|IsString|ApiProperty)" -A 2 -B 2 $(fd "Case.*dto" --type f)
Length of output: 60409 apps/judicial-system/backend/src/app/modules/case/dto/updateCase.dto.ts (1)
The change to add Let's verify similar validation patterns in related DTOs: Consider adding test cases to verify:
Would you like me to help create these test cases? ✅ Verification successfulLet me check the content of these DTOs to see if they have similar array validation patterns that might need the same fix. Let me check the Validation pattern is correctly implemented and consistent The validation for @IsArray()
@ArrayMinSize(1)
@MaxLength(255, { each: true })
@IsString({ each: true })This ensures each police case number in the array:
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Find similar validation patterns in DTOs that might need the same fix
# Look for MaxLength decorators on array properties that might be missing the each:true option
# Search for array properties with MaxLength decorator
rg -U "@IsArray\(\)[^}]*@MaxLength\([^{]*\)" --type ts
# Search for potential DTO files that might need similar validation
fd -e ts -E "*.spec.ts" -E "*.test.ts" --full-path "dto" | xargs rg "@MaxLength" -l
Length of output: 1160 Script: #!/bin/bash
# Check for @IsArray followed by @MaxLength without {each: true} in DTO files
for file in $(fd -e ts -E "*.spec.ts" -E "*.test.ts" --full-path "dto"); do
echo "=== $file ==="
rg -U "@IsArray\(\)[^}]*@MaxLength\([^{]" "$file" -A 1
done
Length of output: 316920 Script: #!/bin/bash
# Check the validation pattern in createCase.dto.ts
cat apps/judicial-system/backend/src/app/modules/case/dto/createCase.dto.ts
Length of output: 1970 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}
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #16930 +/- ##
=======================================
Coverage 36.46% 36.46%
=======================================
Files 6903 6903
Lines 144583 144583
Branches 41283 41283
=======================================
Hits 52718 52718
Misses 91865 91865
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
|
Datadog ReportBranch report: ✅ 0 Failed, 21314 Passed, 0 Skipped, 21m 4.52s Total Time |
* Checkpoint * Refactor AlertMessage * Format date * Cleanup * Cleanup * Merge * Add key * Refactor * Remove console.log * Merge * Merge * Fix e2e * Resolve merge conflict --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com> Co-authored-by: Guðjón Guðjónsson <[email protected]>
Validation fix
Asana
What
In this pr a server side input validation is implemented. There was a slight mistake in the validator for string arrays that caused the e2e tests to fail. This PR fixes that.
Why
So that the e2e tests work again.
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes