Issue 60 done#63
Merged
Merged
Conversation
📝 WalkthroughWalkthroughPatients are integrated into case workflows: patients can create cases for themselves (patientId auto-resolved), view their own non-closed cases, and are recognized in read/create authorization. UI, registration, DTOs, and security-adapter changes support patient persistence and role resolution. Changes
sequenceDiagram
participant Browser
participant UiController
participant CaseService
participant PatientRepo
participant CaseRepo
Browser->>UiController: POST /ui/cases (form)
UiController->>UiController: resolve Actor (current user)
UiController->>CaseService: createCase(actor, caseDTO)
CaseService->>PatientRepo: findById(resolvedPatientId)
alt patient missing and actor is that patient
PatientRepo-->>CaseService: not found
CaseService->>PatientRepo: save(minimal PatientEntity)
PatientRepo-->>CaseService: saved PatientEntity
else patient found
PatientRepo-->>CaseService: found PatientEntity
end
CaseService->>CaseRepo: save(CaseEntity with patient)
CaseRepo-->>CaseService: saved CaseEntity
CaseService-->>UiController: created CaseDTO
UiController-->>Browser: redirect /ui/cases
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/java/org/example/projektarendehantering/application/service/CaseService.java (1)
70-83:⚠️ Potential issue | 🔴 CriticalCritical issue: Patient registration does not create corresponding PatientEntity, causing case creation to fail with 404.
The server-side guard correctly enforces that patients can only create cases for themselves by forcing
requestedPatientId = actor.userId()(line 79), but the lookup at line 88-89 will fail for any patient who registered via the standard registration flow.RegistrationService.registerPatient() creates only a UserAccountEntity with a random UUID. It does NOT create a PatientEntity. When a patient later attempts to create a case, CaseService calls
patientRepository.findById(actor.userId()), which will not find any matching PatientEntity since:
- UserAccountEntity.id is generated via
@PrePersist(UUID.randomUUID())- PatientEntity.id is generated independently via PatientService.createPatient() (a separate, different UUID)
Result: Patients will receive a 404 "Patient not found" error when trying to create cases, even with valid accounts. Fix by either:
- Automatically creating a PatientEntity during user registration (with id matching the new UserAccountEntity.id), or
- Modifying the case creation flow to look up the patient via a relationship (e.g., through a user-patient association) rather than assuming id equality.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/org/example/projektarendehantering/application/service/CaseService.java` around lines 70 - 83, The createCase method enforces patient self-ownership by setting requestedPatientId = actor.userId() but patientRepository.findById(actor.userId()) fails because RegistrationService.registerPatient creates only a UserAccountEntity (UserAccountEntity.id) while PatientEntity.id is generated separately; fix by ensuring a PatientEntity is created at registration with the same id as the new UserAccountEntity (update RegistrationService.registerPatient to create and persist a PatientEntity with id = userAccount.getId() and any required fields) or alternatively change createCase to resolve the PatientEntity via the user->patient relationship (e.g., add a lookup in PatientService that finds PatientEntity by userAccount id or association and use that instead of patientRepository.findById(actor.userId())); update PatientService.createPatient or patientRepository methods as needed to keep ids/associations consistent.
🧹 Nitpick comments (2)
src/main/java/org/example/projektarendehantering/presentation/web/UiController.java (1)
66-96: Consolidate the repeatedactor.role() != Role.PATIENTchecks and guard against a null role.The
actor.role() != Role.PATIENTpredicate is repeated four times acrossnewCase/createCase. Extract a small helper (or useRole.PATIENT.equals(actor.role())) to keep the intent obvious and to avoid subtle drift if more role-specific branches are added.Also, if
actor.role()can ever benull(unauthenticated/misconfigured principal),actor.role() != Role.PATIENTevaluates true and the code will populate the patient dropdown / requirepatientId— harmless here but inconsistent with the template, which explicitly null-checkscurrentActor.role(). Worth aligning.Suggested refactor
+ private static boolean isPatient(Actor actor) { + return actor != null && actor.role() == Role.PATIENT; + } + `@GetMapping`("/ui/cases/new") public String newCase(Model model) { Actor actor = securityActorAdapter.currentUser(); model.addAttribute("createCaseForm", new CreateCaseForm()); - if (actor.role() != Role.PATIENT) { + if (!isPatient(actor)) { model.addAttribute("patients", patientService.getAllPatients()); } return "cases/new"; }Additionally, there are two trailing lines (170–171) containing only whitespace — please trim.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/org/example/projektarendehantering/presentation/web/UiController.java` around lines 66 - 96, The repeated checks of actor.role() != Role.PATIENT in newCase and createCase should be consolidated and null-safe: add a small helper like isPatient(Actor) (or inline use Role.PATIENT.equals(actor.role())) and replace all occurrences in newCase and createCase with that helper to avoid repetition and accidental null-handling differences; ensure createCase uses the null-safe check when deciding to add patients to the model and when validating form.getPatientId(), and keep the patient selection logic consistent with securityActorAdapter.currentUser(); also remove the two trailing whitespace-only lines near the end of UiController to trim stray whitespace.src/main/resources/templates/cases/new.html (1)
15-25: Role gating via string comparison is brittle; consider enum comparison.
currentActor.role().toString() != 'PATIENT'relies on the enum'stoString()matching the literal string. If theRoleenum ever overridestoString()(e.g., for i18n/display), this guard silently breaks and the patient dropdown would be rendered again for patients (a privacy/authorization-visible inconsistency, though the server still enforces it inCaseService). Prefer comparing against the enum directly using Thymeleaf'sT(...)operator:Proposed fix
- <label class="field" th:if="${currentActor == null || currentActor.role() == null || currentActor.role().toString() != 'PATIENT'}"> + <label class="field" th:if="${currentActor == null || currentActor.role() == null || currentActor.role() != T(org.example.projektarendehantering.common.Role).PATIENT}"> ... - <p class="muted" th:if="${currentActor != null && currentActor.role() != null && currentActor.role().toString() == 'PATIENT'}"> + <p class="muted" th:if="${currentActor != null && currentActor.role() != null && currentActor.role() == T(org.example.projektarendehantering.common.Role).PATIENT}">Also, consider exposing a simple boolean model attribute (e.g.,
isPatient) from the controller to keep the template free of this duplicated conditional.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/resources/templates/cases/new.html` around lines 15 - 25, The template uses a brittle string comparison currentActor.role().toString() == 'PATIENT'; change the guard to compare against the Role enum directly using Thymeleaf's T(...) operator (e.g., currentActor.role() == T(com.example.yourpkg.Role).PATIENT) for both the label and the paragraph, or alternatively add a boolean model attribute (e.g., isPatient) from the controller and use that (isPatient) in the th:if expressions to keep the template simpler; update the th:if conditions around currentActor, currentActor.role() and the patient dropdown/paragraph to use the enum comparison or the new boolean attribute consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/main/java/org/example/projektarendehantering/presentation/web/AuthController.java`:
- Line 20: Remove the stray placeholder comment from AuthController: delete the
line containing "// Just a guy tryna let me commit smth new a wierd" in the
AuthController class so the source contains no unrelated or typo-filled
comments; ensure only meaningful documentation or TODOs remain in class
AuthController and run a quick compile to verify no accidental whitespace or
encoding changes were introduced.
In
`@src/main/java/org/example/projektarendehantering/presentation/web/PatientUiController.java`:
- Around line 14-15: Remove the stray debug comment "// Something wierd" from
the PatientUiController file; locate the PatientUiController class (or its
top-of-file comments/imports) and delete that comment to avoid noise and correct
the typo (weird).
---
Outside diff comments:
In
`@src/main/java/org/example/projektarendehantering/application/service/CaseService.java`:
- Around line 70-83: The createCase method enforces patient self-ownership by
setting requestedPatientId = actor.userId() but
patientRepository.findById(actor.userId()) fails because
RegistrationService.registerPatient creates only a UserAccountEntity
(UserAccountEntity.id) while PatientEntity.id is generated separately; fix by
ensuring a PatientEntity is created at registration with the same id as the new
UserAccountEntity (update RegistrationService.registerPatient to create and
persist a PatientEntity with id = userAccount.getId() and any required fields)
or alternatively change createCase to resolve the PatientEntity via the
user->patient relationship (e.g., add a lookup in PatientService that finds
PatientEntity by userAccount id or association and use that instead of
patientRepository.findById(actor.userId())); update PatientService.createPatient
or patientRepository methods as needed to keep ids/associations consistent.
---
Nitpick comments:
In
`@src/main/java/org/example/projektarendehantering/presentation/web/UiController.java`:
- Around line 66-96: The repeated checks of actor.role() != Role.PATIENT in
newCase and createCase should be consolidated and null-safe: add a small helper
like isPatient(Actor) (or inline use Role.PATIENT.equals(actor.role())) and
replace all occurrences in newCase and createCase with that helper to avoid
repetition and accidental null-handling differences; ensure createCase uses the
null-safe check when deciding to add patients to the model and when validating
form.getPatientId(), and keep the patient selection logic consistent with
securityActorAdapter.currentUser(); also remove the two trailing whitespace-only
lines near the end of UiController to trim stray whitespace.
In `@src/main/resources/templates/cases/new.html`:
- Around line 15-25: The template uses a brittle string comparison
currentActor.role().toString() == 'PATIENT'; change the guard to compare against
the Role enum directly using Thymeleaf's T(...) operator (e.g.,
currentActor.role() == T(com.example.yourpkg.Role).PATIENT) for both the label
and the paragraph, or alternatively add a boolean model attribute (e.g.,
isPatient) from the controller and use that (isPatient) in the th:if expressions
to keep the template simpler; update the th:if conditions around currentActor,
currentActor.role() and the patient dropdown/paragraph to use the enum
comparison or the new boolean attribute consistently.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 24925949-3bf6-481d-a630-624224ea613e
📒 Files selected for processing (7)
src/main/java/org/example/projektarendehantering/application/service/CaseService.javasrc/main/java/org/example/projektarendehantering/presentation/dto/CreateCaseForm.javasrc/main/java/org/example/projektarendehantering/presentation/web/AuthController.javasrc/main/java/org/example/projektarendehantering/presentation/web/PatientUiController.javasrc/main/java/org/example/projektarendehantering/presentation/web/UiController.javasrc/main/resources/templates/cases/new.htmlsrc/test/java/org/example/projektarendehantering/application/service/CaseServiceTest.java
💤 Files with no reviewable changes (1)
- src/main/java/org/example/projektarendehantering/presentation/dto/CreateCaseForm.java
| @RequiredArgsConstructor | ||
| public class AuthController { | ||
|
|
||
| // Just a guy tryna let me commit smth new a wierd |
There was a problem hiding this comment.
Remove the stray commit-placeholder comment.
// Just a guy tryna let me commit smth new a wierd looks like a placeholder to force a commit and contains typos. It's unrelated to the PR objectives (patient role support) and should be removed before merge.
Proposed fix
-// Just a guy tryna let me commit smth new a wierd
private final RegistrationService registrationService;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| // Just a guy tryna let me commit smth new a wierd | |
| private final RegistrationService registrationService; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/main/java/org/example/projektarendehantering/presentation/web/AuthController.java`
at line 20, Remove the stray placeholder comment from AuthController: delete the
line containing "// Just a guy tryna let me commit smth new a wierd" in the
AuthController class so the source contains no unrelated or typo-filled
comments; ensure only meaningful documentation or TODOs remain in class
AuthController and run a quick compile to verify no accidental whitespace or
encoding changes were introduced.
Comment on lines
+14
to
+15
| // Something wierd | ||
|
|
There was a problem hiding this comment.
Remove the stray debug comment.
// Something wierd appears to be an unintended artifact (also misspelled — "weird"). Please delete before merging; it adds noise and is unrelated to this PR's scope.
Proposed fix
-// Something wierd
-
`@Controller`
public class PatientUiController {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| // Something wierd | |
| `@Controller` | |
| public class PatientUiController { |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/main/java/org/example/projektarendehantering/presentation/web/PatientUiController.java`
around lines 14 - 15, Remove the stray debug comment "// Something wierd" from
the PatientUiController file; locate the PatientUiController class (or its
top-of-file comments/imports) and delete that comment to avoid noise and correct
the typo (weird).
…lowed firstname/lastname input
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/main/resources/templates/login/register.html (1)
26-30: Optional: mirror the server-side pattern on the client input.You could add
pattern="\d{8}-\d{4}"(and optionallyinputmode="numeric" maxlength="13") to the personal identity number input so invalid formats are caught immediately by the browser and the user doesn't need a round-trip to see the error.♻️ Suggested refinement
- <input type="text" id="personalIdentityNumber" th:field="*{personalIdentityNumber}" class="input" placeholder="YYYYMMDD-XXXX" required> + <input type="text" id="personalIdentityNumber" th:field="*{personalIdentityNumber}" class="input" + placeholder="YYYYMMDD-XXXX" pattern="\d{8}-\d{4}" inputmode="numeric" maxlength="13" required>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/resources/templates/login/register.html` around lines 26 - 30, Add client-side validation attributes to the personal identity number input to mirror the server-side pattern: update the input with id "personalIdentityNumber" (th:field="*{personalIdentityNumber}") to include pattern="\d{8}-\d{4}" and optionally inputmode="numeric" and maxlength="13" so the browser validates the YYYYMMDD-XXXX format before submitting.src/main/java/org/example/projektarendehantering/presentation/dto/PatientRegistrationDTO.java (1)
19-21: Optional: tighten the personal identity number validation.The regex
^\d{8}-\d{4}$accepts clearly invalid values such as99999999-9999or00000000-0000. Since the backend relies on this value for patient uniqueness, consider validating the date portion (month 01-12, day 01-31) and/or the standard Luhn checksum used by Swedish personnummer. A more restrictive regex for the date section:♻️ Suggested tighter pattern
- `@Pattern`(regexp = "^\\d{8}-\\d{4}$", message = "Use format YYYYMMDD-XXXX") + `@Pattern`( + regexp = "^(19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])-\\d{4}$", + message = "Use format YYYYMMDD-XXXX") private String personalIdentityNumber;Full checksum validation typically requires a custom
ConstraintValidator.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/org/example/projektarendehantering/presentation/dto/PatientRegistrationDTO.java` around lines 19 - 21, The personalIdentityNumber field in PatientRegistrationDTO currently uses a permissive `@Pattern`; tighten validation by either replacing that regex with one that enforces a valid date segment (year, month 01-12, day 01-31) or, preferably, implement a custom Bean Validation annotation and validator to perform full Swedish personnummer checks (including Luhn checksum). Create an annotation (e.g., `@ValidPersonnummer`) and a ConstraintValidator (e.g., PersonnummerValidator implements ConstraintValidator<ValidPersonnummer, String>) that verifies format, valid date portion and checksum, then annotate PatientRegistrationDTO.personalIdentityNumber with `@NotBlank` and `@ValidPersonnummer` and update the validation message to reflect the stricter rule.src/main/java/org/example/projektarendehantering/application/service/RegistrationService.java (1)
55-61: Consider modeling the User↔Patient relationship at the JPA level.Today
PatientEntity.idis manually set fromsavedAccount.getId()andcreatedAtis copy-propagated from the user account's@PrePersistside effect. There is no@OneToOne,@MapsId, or FK constraint linking the two tables, so:
- Database-level referential integrity between
patients.idanduser_accounts.idis not enforced; orphan rows or mismatched ids can exist if future code paths diverge.patientEntity.setCreatedAt(savedAccount.getCreatedAt())implicitly depends onUserAccountEntity.@PrePersisthaving already fired on save — a subtle coupling that will silently break if that hook is refactored. LettingPatientEntityown its own@PrePersist(or@CreationTimestamp) avoids this.A more idiomatic mapping on
PatientEntity:Suggested JPA relationship mapping
`@OneToOne`(fetch = FetchType.LAZY) `@MapsId` `@JoinColumn`(name = "id") private UserAccountEntity userAccount;Then use
patientEntity.setUserAccount(savedAccount)— JPA will derive the id and enforce the FK at the DB layer.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/org/example/projektarendehantering/application/service/RegistrationService.java` around lines 55 - 61, PatientEntity is being manually assigned savedAccount.getId() and copying createdAt, which risks referential integrity and hidden coupling; change the JPA model so PatientEntity has a proper one-to-one mapping to UserAccountEntity (use `@OneToOne`(fetch = FetchType.LAZY) together with `@MapsId` and `@JoinColumn`(name = "id") on the userAccount field), stop calling patientEntity.setId(...) and patientEntity.setCreatedAt(...), and instead call patientEntity.setUserAccount(savedAccount) before patientRepository.save(patientEntity); also let PatientEntity own its timestamp (use its own `@PrePersist` or `@CreationTimestamp`) so createdAt is not copied from the user account.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/main/java/org/example/projektarendehantering/application/service/RegistrationService.java`:
- Around line 52-64: In RegistrationService where
userAccountRepository.save(newUserAccount) and
patientRepository.save(patientEntity) are wrapped in a single try/catch for
DataIntegrityViolationException, differentiate which unique constraint failed
and throw the correct BadRequestException (USER_EXISTS vs PATIENT_EXISTS):
either split into two save blocks with their own try/catch around
userAccountRepository.save(...) and patientRepository.save(...), or inspect the
exception root cause (e.g., unwrap to ConstraintViolationException and check the
constraint name or SQL state from ex.getRootCause()) and map that to throw new
BadRequestException("USER_EXISTS", ...) or new
BadRequestException("PATIENT_EXISTS", ...) accordingly.
In
`@src/main/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapter.java`:
- Line 57: The call in SecurityActorAdapter that normalizes the email before
lookup
(userAccountRepository.findByEmail(authentication.getName().trim().toLowerCase()))
is locale-sensitive; change the normalization to use a locale-independent
lowercasing (use Locale.ROOT with the toLowerCase call) so lookups are stable
across JVM locales, and verify the registration/write path also persists emails
lowercased (so the repository lookup and the write path use the same
normalization).
---
Nitpick comments:
In
`@src/main/java/org/example/projektarendehantering/application/service/RegistrationService.java`:
- Around line 55-61: PatientEntity is being manually assigned
savedAccount.getId() and copying createdAt, which risks referential integrity
and hidden coupling; change the JPA model so PatientEntity has a proper
one-to-one mapping to UserAccountEntity (use `@OneToOne`(fetch = FetchType.LAZY)
together with `@MapsId` and `@JoinColumn`(name = "id") on the userAccount field),
stop calling patientEntity.setId(...) and patientEntity.setCreatedAt(...), and
instead call patientEntity.setUserAccount(savedAccount) before
patientRepository.save(patientEntity); also let PatientEntity own its timestamp
(use its own `@PrePersist` or `@CreationTimestamp`) so createdAt is not copied from
the user account.
In
`@src/main/java/org/example/projektarendehantering/presentation/dto/PatientRegistrationDTO.java`:
- Around line 19-21: The personalIdentityNumber field in PatientRegistrationDTO
currently uses a permissive `@Pattern`; tighten validation by either replacing
that regex with one that enforces a valid date segment (year, month 01-12, day
01-31) or, preferably, implement a custom Bean Validation annotation and
validator to perform full Swedish personnummer checks (including Luhn checksum).
Create an annotation (e.g., `@ValidPersonnummer`) and a ConstraintValidator (e.g.,
PersonnummerValidator implements ConstraintValidator<ValidPersonnummer, String>)
that verifies format, valid date portion and checksum, then annotate
PatientRegistrationDTO.personalIdentityNumber with `@NotBlank` and
`@ValidPersonnummer` and update the validation message to reflect the stricter
rule.
In `@src/main/resources/templates/login/register.html`:
- Around line 26-30: Add client-side validation attributes to the personal
identity number input to mirror the server-side pattern: update the input with
id "personalIdentityNumber" (th:field="*{personalIdentityNumber}") to include
pattern="\d{8}-\d{4}" and optionally inputmode="numeric" and maxlength="13" so
the browser validates the YYYYMMDD-XXXX format before submitting.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e3180eba-cbad-417f-a3eb-5c61836fcfd9
📒 Files selected for processing (5)
src/main/java/org/example/projektarendehantering/application/service/CaseService.javasrc/main/java/org/example/projektarendehantering/application/service/RegistrationService.javasrc/main/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapter.javasrc/main/java/org/example/projektarendehantering/presentation/dto/PatientRegistrationDTO.javasrc/main/resources/templates/login/register.html
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/org/example/projektarendehantering/application/service/CaseService.java
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/test/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapterTest.java (1)
114-114: Stubs pass coincidentally; normalization path is untested.Production
currentUser()callsuserAccountRepository.findByEmail(authentication.getName().trim().toLowerCase(Locale.ROOT))(seeSecurityActorAdapter.java:59). These stubs work only because every test name is already lowercase and untrimmed ("some-other-name","manager-user", etc.). Consider adding at least one test with mixed-case/whitespace input (e.g.," Manager-User ") stubbingfindByEmail("manager-user")to lock in the normalization contract — otherwise a regression that removes.trim().toLowerCase(...)would go undetected.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapterTest.java` at line 114, Add a test in SecurityActorAdapterTest that asserts normalization by calling currentUser() with an Authentication name containing mixed case and surrounding whitespace (e.g., " Manager-User "), and stub userAccountRepository.findByEmail with the normalized form "manager-user" (the value currentUser() passes after .trim().toLowerCase(Locale.ROOT)); specifically update the when(...) stub used in the test (replace or add the existing when(userAccountRepository.findByEmail("some-other-name")).thenReturn(Optional.empty()) pattern) so it uses the normalized key and verify the adapter still returns the expected user, thereby locking in the trim()/toLowerCase() contract referenced in SecurityActorAdapter.currentUser().
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@src/test/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapterTest.java`:
- Line 114: Add a test in SecurityActorAdapterTest that asserts normalization by
calling currentUser() with an Authentication name containing mixed case and
surrounding whitespace (e.g., " Manager-User "), and stub
userAccountRepository.findByEmail with the normalized form "manager-user" (the
value currentUser() passes after .trim().toLowerCase(Locale.ROOT)); specifically
update the when(...) stub used in the test (replace or add the existing
when(userAccountRepository.findByEmail("some-other-name")).thenReturn(Optional.empty())
pattern) so it uses the normalized key and verify the adapter still returns the
expected user, thereby locking in the trim()/toLowerCase() contract referenced
in SecurityActorAdapter.currentUser().
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d5ab8d21-084f-495b-abdb-a2c00c578fd5
📒 Files selected for processing (4)
src/main/java/org/example/projektarendehantering/application/service/RegistrationService.javasrc/main/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapter.javasrc/main/java/org/example/projektarendehantering/presentation/web/AuthController.javasrc/test/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapterTest.java
✅ Files skipped from review due to trivial changes (1)
- src/main/java/org/example/projektarendehantering/presentation/web/AuthController.java
🚧 Files skipped from review as they are similar to previous changes (2)
- src/main/java/org/example/projektarendehantering/application/service/RegistrationService.java
- src/main/java/org/example/projektarendehantering/infrastructure/security/SecurityActorAdapter.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #60
Summary by CodeRabbit
New Features
Bug Fixes / Validation