Adds Salmonellosis disease in relation to exposure, symptoms & Hospitalization#13921
Open
roldy wants to merge 8 commits intodevelopmentfrom
Open
Adds Salmonellosis disease in relation to exposure, symptoms & Hospitalization#13921roldy wants to merge 8 commits intodevelopmentfrom
roldy wants to merge 8 commits intodevelopmentfrom
Conversation
… PersonDto, PersonEditForm & schema to support SAL disease
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThis pull request introduces comprehensive Salmonellosis disease surveillance support to SORMAS for Luxembourg. It adds a new Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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. Review rate limit: 0/1 reviews remaining, refill in 9 minutes and 22 seconds.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: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
sormas-ui/src/main/java/de/symeda/sormas/ui/exposure/ExposureForm.java (1)
327-440:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winExisting eating-out data can be silently cleared on edit
The new fields are cleared by the sub-settings listener during
setValuere-initialization, but they are never restored afterward. This can null out existingEATING_OUT_VENUES,EATING_OUT_VENUE_OTHER, andSHOPPING_FOR_FOOD_DETAILSon save.💡 Suggested fix
@@ - OptionGroup eatingOutVenuesField = addField(exposureDetailsLayout, ExposureDto.EATING_OUT_VENUES, OptionGroup.class); + eatingOutVenuesField = addField(exposureDetailsLayout, ExposureDto.EATING_OUT_VENUES, OptionGroup.class); @@ - TextField eatingOutVenueOtherField = addField(exposureDetailsLayout, ExposureDto.EATING_OUT_VENUE_OTHER, TextField.class); + eatingOutVenueOtherField = addField(exposureDetailsLayout, ExposureDto.EATING_OUT_VENUE_OTHER, TextField.class); @@ - TextField shoppingForFoodDetailsField = addField(exposureDetailsLayout, ExposureDto.SHOPPING_FOR_FOOD_DETAILS, TextField.class); + shoppingForFoodDetailsField = addField(exposureDetailsLayout, ExposureDto.SHOPPING_FOR_FOOD_DETAILS, TextField.class);@@ - TravelPurpose travelPurpose = newFieldValue.getTravelPurpose(); + TravelPurpose travelPurpose = newFieldValue.getTravelPurpose(); String travelPurposeDetails = newFieldValue.getTravelPurposeDetails(); + Set<EatingOutVenue> eatingOutVenues = newFieldValue.getEatingOutVenues(); + String eatingOutVenueOther = newFieldValue.getEatingOutVenueOther(); + String shoppingForFoodDetails = newFieldValue.getShoppingForFoodDetails(); @@ if (subSettings != null && !subSettings.isEmpty()) { subSettingsField.setValue(subSettings); } + boolean hasEatingOutside = subSettings != null && subSettings.contains(ExposureSubSetting.EATING_OUTSIDE); + eatingOutVenuesField.setVisible(hasEatingOutside); + if (hasEatingOutside && eatingOutVenues != null && !eatingOutVenues.isEmpty()) { + eatingOutVenuesField.setValue(eatingOutVenues); + } + boolean hasEatingOutOther = eatingOutVenues != null && eatingOutVenues.contains(EatingOutVenue.OTHER); + eatingOutVenueOtherField.setVisible(hasEatingOutside && hasEatingOutOther); + eatingOutVenueOtherField.setValue(hasEatingOutside && hasEatingOutOther ? eatingOutVenueOther : null); + + boolean hasShoppingForFood = subSettings != null && subSettings.contains(ExposureSubSetting.SHOPPING_FOR_FOOD); + shoppingForFoodDetailsField.setVisible(hasShoppingForFood); + shoppingForFoodDetailsField.setValue(hasShoppingForFood ? shoppingForFoodDetails : null);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sormas-ui/src/main/java/de/symeda/sormas/ui/exposure/ExposureForm.java` around lines 327 - 440, The subSettingsField listener clears eatingOutVenuesField, eatingOutVenueOtherField and shoppingForFoodDetailsField during setValue re-initialization but nothing restores them afterward; fix by, after loading the DTO into the form (or after setValue), re-applying the same visibility/value restoration logic used in the subSettingsField listener: read the current subSettings (subSettingsField.getValue()), compute showEatingOutVenues and showShoppingForFood, set eatingOutVenuesField.setVisible(...), eatingOutVenuesField.setValue(...) from the DTO if present, set eatingOutVenueOtherField visibility/value based on whether EatingOutVenue.OTHER is selected, and set shoppingForFoodDetailsField visibility/value from the DTO; you can centralize this into a helper method (e.g., restoreEatingOutAndShoppingFields) and call it from the form initialization path so eatingOut fields are not lost on edit/save.sormas-api/src/main/java/de/symeda/sormas/api/symptoms/SymptomsDto.java (1)
405-430:⚠️ Potential issue | 🟠 Major | ⚡ Quick winSALMONELLOSIS rollout is incomplete for onset capture fields.
You added SALMONELLOSIS to many symptom fields, but
onsetDateandonsetSymptomstill don’t include it (Line 1391 and Line 1461 blocks). That prevents capturing core onset data for Salmonellosis cases.Suggested fix
@@ `@Diseases`({ AFP, CHOLERA, @@ PERTUSSIS, + SALMONELLOSIS, GIARDIASIS, CRYPTOSPORIDIOSIS }) `@HideForCountries` `@Outbreaks` private Date onsetDate; @@ `@Diseases`({ AFP, CHOLERA, @@ INVASIVE_PNEUMOCOCCAL_INFECTION, FHA, + SALMONELLOSIS, PERTUSSIS }) `@HideForCountries` `@Size`(max = FieldConstraints.CHARACTER_LIMIT_DEFAULT, message = Validations.textTooLong) private String onsetSymptom;Also applies to: 494-495, 692-693, 716-717, 847-848, 906-907, 995-996, 1299-1300, 1327-1328, 1591-1592, 1615-1616, 1822-1823, 2106-2107
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sormas-api/src/main/java/de/symeda/sormas/api/symptoms/SymptomsDto.java` around lines 405 - 430, The SALMONELLOSIS enum was added to many symptom `@Diseases` lists but not added to the corresponding onset capture lists; update the SymptomsDto entries that define onsetDate and onsetSymptom (the fields/methods named onsetDate and onsetSymptom within SymptomsDto) to include SALMONELLOSIS in their `@Diseases` annotations so onsetDate/onsetSymptom capture Salmonellosis cases as well; mirror the same inclusion pattern used for other symptoms (add SALMONELLOSIS to the same disease arrays where related symptoms include it).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@sormas-api/src/main/java/de/symeda/sormas/api/Disease.java`:
- Line 93: The new enum constant SALMONELLOSIS was added to Disease but
CssStyles.getDiseaseCssClass lacks a corresponding case, causing a fallback to
background-disease-undefined; update the switch in CssStyles.getDiseaseCssClass
to add a case for Disease.SALMONELLOSIS that returns the intended CSS class
(e.g., "background-disease-salmonellosis" or your project's naming convention),
ensuring the method handles this value like the other disease cases.
In `@sormas-backend/src/main/java/de/symeda/sormas/backend/epidata/EpiData.java`:
- Around line 316-327: The setters for the exposure investigation range
currently allow inverted intervals; update setExposureInvestigationFromDate(Date
exposureInvestigationFromDate) and setExposureInvestigationToDate(Date
exposureInvestigationToDate) (and the other analogous date-range setter pairs in
this class) to enforce from <= to by normalizing inputs: if the counterpart date
is non-null and the new value would invert the interval, swap the two values
(i.e., set the earlier date to the min and the later to the max) before
assigning fields; implement this logic inside each setter so persistence via
imports/API cannot create inverted ranges.
In `@sormas-backend/src/main/resources/sql/sormas_schema.sql`:
- Around line 15861-15865: The delete-history trigger call references a
non-existent key column 'id' for the exposures_eatingoutvenues table; update the
trigger invocation delete_history_trigger('exposures_eatingoutvenues_history',
'id') to use the actual key column name used by the table (exposure_id) or the
correct composite/primary key if different, ensuring the history trigger refers
to exposure_id to match the table schema (look for exposures_eatingoutvenues and
its delete_history_trigger registration).
In `@sormas-ui/src/main/java/de/symeda/sormas/ui/epidata/EpiDataForm.java`:
- Around line 256-259: The activity-as-case date fields
EpiDataDto.ACTIVITY_AS_CASE_FROM_DATE and EpiDataDto.ACTIVITY_AS_CASE_TO_DATE
are being added unconditionally; scope their addField calls to the same
case-only branch used elsewhere by checking parentClass == CaseDataDto before
calling addField (i.e., move or wrap the
addField(EpiDataDto.ACTIVITY_AS_CASE_FROM_DATE, DateField.class) and
addField(EpiDataDto.ACTIVITY_AS_CASE_TO_DATE, DateField.class) inside the
existing parentClass == CaseDataDto block so these fields are only registered
for CaseDataDto contexts).
In
`@sormas-ui/src/main/java/de/symeda/sormas/ui/hospitalization/HospitalizationForm.java`:
- Line 176: In HospitalizationForm ensure Salmonellosis participates in the ICU
visibility gate: remove Disease.SALMONELLOSIS from the exclusion List.of(...)
check (the one comparing caze.getDisease()) or alternatively add
Disease.SALMONELLOSIS to the earlier allowed set that controls visibility so
that INTENSIVE_CARE_UNIT, INTENSIVE_CARE_UNIT_START and INTENSIVE_CARE_UNIT_END
are shown for Salmonellosis; update the logic around the caze disease checks so
both the earlier visibility branch and the later List.of(...) check are
consistent.
In `@sormas-ui/src/main/java/de/symeda/sormas/ui/person/PersonEditForm.java`:
- Around line 528-531: When hiding the enum field PersonDto.WORK_PLACE for
Luxembourg Salmonellosis (the isLuxSalmonellosis branch), clear any existing
value so stale enum data cannot persist while only PersonDto.WORK_PLACE_TEXT is
edited; after calling setVisible(false, PersonDto.WORK_PLACE) reset/clear the
underlying value (e.g., set the WORK_PLACE field value to null via the field or
DTO) before making PersonDto.WORK_PLACE_TEXT visible.
---
Outside diff comments:
In `@sormas-api/src/main/java/de/symeda/sormas/api/symptoms/SymptomsDto.java`:
- Around line 405-430: The SALMONELLOSIS enum was added to many symptom
`@Diseases` lists but not added to the corresponding onset capture lists; update
the SymptomsDto entries that define onsetDate and onsetSymptom (the
fields/methods named onsetDate and onsetSymptom within SymptomsDto) to include
SALMONELLOSIS in their `@Diseases` annotations so onsetDate/onsetSymptom capture
Salmonellosis cases as well; mirror the same inclusion pattern used for other
symptoms (add SALMONELLOSIS to the same disease arrays where related symptoms
include it).
In `@sormas-ui/src/main/java/de/symeda/sormas/ui/exposure/ExposureForm.java`:
- Around line 327-440: The subSettingsField listener clears
eatingOutVenuesField, eatingOutVenueOtherField and shoppingForFoodDetailsField
during setValue re-initialization but nothing restores them afterward; fix by,
after loading the DTO into the form (or after setValue), re-applying the same
visibility/value restoration logic used in the subSettingsField listener: read
the current subSettings (subSettingsField.getValue()), compute
showEatingOutVenues and showShoppingForFood, set
eatingOutVenuesField.setVisible(...), eatingOutVenuesField.setValue(...) from
the DTO if present, set eatingOutVenueOtherField visibility/value based on
whether EatingOutVenue.OTHER is selected, and set shoppingForFoodDetailsField
visibility/value from the DTO; you can centralize this into a helper method
(e.g., restoreEatingOutAndShoppingFields) and call it from the form
initialization path so eatingOut fields are not lost on edit/save.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 17348764-684a-46f3-845c-72bd4dc96935
📒 Files selected for processing (22)
sormas-api/src/main/java/de/symeda/sormas/api/Disease.javasormas-api/src/main/java/de/symeda/sormas/api/epidata/EpiDataDto.javasormas-api/src/main/java/de/symeda/sormas/api/exposure/EatingOutVenue.javasormas-api/src/main/java/de/symeda/sormas/api/exposure/ExposureDto.javasormas-api/src/main/java/de/symeda/sormas/api/exposure/ExposureSubSetting.javasormas-api/src/main/java/de/symeda/sormas/api/hospitalization/HospitalizationDto.javasormas-api/src/main/java/de/symeda/sormas/api/i18n/Captions.javasormas-api/src/main/java/de/symeda/sormas/api/person/PersonDto.javasormas-api/src/main/java/de/symeda/sormas/api/symptoms/SymptomsDto.javasormas-api/src/main/resources/captions.propertiessormas-api/src/main/resources/enum.propertiessormas-backend/src/main/java/de/symeda/sormas/backend/epidata/EpiData.javasormas-backend/src/main/java/de/symeda/sormas/backend/epidata/EpiDataFacadeEjb.javasormas-backend/src/main/java/de/symeda/sormas/backend/exposure/Exposure.javasormas-backend/src/main/java/de/symeda/sormas/backend/symptoms/Symptoms.javasormas-backend/src/main/java/de/symeda/sormas/backend/symptoms/SymptomsFacadeEjb.javasormas-backend/src/main/resources/sql/sormas_schema.sqlsormas-ui/src/main/java/de/symeda/sormas/ui/epidata/EpiDataForm.javasormas-ui/src/main/java/de/symeda/sormas/ui/exposure/ExposureForm.javasormas-ui/src/main/java/de/symeda/sormas/ui/hospitalization/HospitalizationForm.javasormas-ui/src/main/java/de/symeda/sormas/ui/person/PersonEditForm.javasormas-ui/src/main/java/de/symeda/sormas/ui/symptoms/SymptomsForm.java
…id column & uses a composite pk on exposure_id & eatingoutvenue
…now added only when parentClass == CaseDataDto.class, alongside the rest of the activity-as-case block.
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.
Fixes #13914, #13915, #13916
Summary by CodeRabbit