Both app_de.arb (line 12: "selectOrganisation":"Wählen Sie Organisation") and app_hi.arb (line 12: "selectOrganisation": "संगठन चुनें") will retain the old unused key alongside the new "chooseOrganisation". Remove the stale keys.

The existing app_de.arb uses no space after colons: "key":"value". The new entries use spaces: "key": "value". Pick one

Adding @@locale is a good practice, but only adding it to 2 of 4 files creates inconsistency. Either add "@@locale": "en" and "@@locale": "ar" to the other files in this MR, or leave all files without it and address it in a separate MR.

Thanks @kartikaeyy for your contribution!

Saptarshi Purkayastha (a3c51f4f) at 02 Mar 01:24

... and 1 more commit

Description

The Arabic (app_ar.arb) locale file is missing 2 translation keys that exist in the English source file.

Missing Keys

Arabic (lib/l10n/app_ar.arb) - 2 missing:

• addBabyDetails
• updateBabyDetails

English Source Values

"addBabyDetails": "Add Baby Details",
"updateBabyDetails": "Update Baby Details"

Acceptance Criteria

• Add the 2 missing keys to lib/l10n/app_ar.arb with correct Arabic translations
• Ensure proper RTL text direction is considered
• Run flutter gen-l10n successfully
• Verify the app compiles with no localization errors

Skills Evaluated

• Flutter localization fundamentals
• RTL language awareness
• Build verification workflow

this MR fixes #121 with all the criteria mentioned

• Add the 2 missing keys to lib/l10n/app_ar.arb with correct Arabic translations
• Ensure proper RTL text direction is considered
• Run flutter gen-l10n successfully
• Verify the app compiles with no localization errors

Both app_de.arb (line 12) and app_hi.arb (line 12) currently have "selectOrganisation". This MR adds "chooseOrganisation" (which matches app_en.arb) but does NOT remove the old "selectOrganisation" key.

1. The new constant userInfoColor = Color(0xff3080ED) is the exact same color as primaryBlue = Color(0xff3080ED) already defined at constants.dart:3. Don't introduce a new name. Just use primaryBlue in user_info.dart.

2. Color(0xff3080ED) appears at lines 205 and 259 of lib/screens/authentication/select_organisation/select_organisation.dart. These should be replaced with the existing primaryBlue constant. The MR claims 13 audited instances but only replaces 11.

3. The issue asks for "meaningful named constants." Names tied to specific widgets/screens defeat the purpose of centralization — if another screen needs the same color, the developer won't think to use tempScreenInactiveBgColor or notificationCardBlueTextColor.

1. test/fetch_baby_bloc_test/fetch_baby_bloc_test.mocks.dart (432 lines) is auto-generated by Mockito's build_runner. It should be in .gitignore. Same recurring issue as MRs !97 and !108.

2. The mockInfants list at line 62 is at 2-space indent (top-level scope), but it's inside the setUp() body which uses 4-space indent (see familyProfile and providerProfile above it). This is a copy-paste formatting error.

3. In the bloc, getUserProfile() is called OUTSIDE the try-catch block (line 25), while getInfantsFromServer() is inside it (line 28). If getUserProfile() throws, the exception is unhandled and the bloc crashes, no FetchInfantFromServerError is emitted. Add a test that mocks getUserProfile() to throw to document (or fix) this gap.

4. The test asserts isA() but doesn't verify the exception string. The bloc passes e.toString() to the state — use a predicate to verify the message content, consistent with the other tests in this MR that do validate data.

5. The import 'dart:async'; is unused and should be removed.

@AnhDai317 a new issue has been introduced. Please let me know if I am reading this incorrectly.

The MR adds a complete class AddBaby extends StatefulWidget definition to add_baby_input.dart (with _formKey, all controllers, Form wrapper, full build method ~210 lines). But add_baby.dart already defines class AddBaby (also modified in this MR) AND imports add_baby_input.dart at line 10

2. At line 913 (after selecting a mother in the slide-up dialog), Form.of(context)?.validate() is called. But dialogs create a separate widget tree via overlays — the dialog's context does not have the main Form as an ancestor. This call does nothing. The same applies to the Form.of(context)?.validate() after date/time picker selection

3. When a future date or future time is detected, the validator returns invalidInput ("Invalid Input"). For a medical form, a specific message like "Date cannot be in the future" is more helpful for the user.

1. useMaterial3: true is a high-risk visual overhaul. This is not mentioned in the issue or MR description, but it fundamentally changes how Flutter renders many widgets.

2. ColorScheme.fromSeed does NOT preserve the exact primary color. ColorScheme.fromSeed(seedColor: primary) generates a harmonized color palette where the actual colorScheme.primary will likely differ from #6E2A7F. This is by design due to how Material 3 tonal palettes shift the hue. Meanwhile, 48 widget instances still hardcode the primary constant (Color(0xff6E2A7F)), creating a mismatch between theme-derived colors and hardcoded colors.

3. elevatedButtonTheme padding change can break layouts. The original theme only set backgroundColor.'

4. inputDecorationTheme conflicts with existing hardcoded styles. The new theme sets borderRadius: 8 (rounded), but existing input fields (75 instances across 10 files) use borderRadius: 0 (rectangular/sharp corners).

5. appBarTheme silently changes all AppBars. centerTitle: true means that every AppBar now centers its title. Screens that had left-aligned titles (the Flutter default) will shift.

1. Broken indentation in getUserFromDhis2 method gained 2 extra spaces of indentation (4-space indent instead of 2-space). Every line in the method body is now misaligned with the rest of the class (getConversationOfUser, fetchChatsOfChatRoom, etc.).

2. The new try-catch catches all exceptions, not just network errors. This silently swallows programming errors (null dereference, type cast failures, etc.) making debugging harder. Consider catching specific exceptions

3. test/message_bloc_test/message_bloc_test.mocks.dart is auto-generated by Mockito's build_runner. It should be in .gitignore and regenerated via dart run build_runner build. Same feedback given on MR !97.

4. No test for user de-duplication logic in getUserFromDhis2. The bloc has merge logic that combines alreadyPresentChats with DHIS2 users, excluding duplicates by recieverId. The test passes an empty list [] for userAlreadyPresent, so this logic is never exercised.

5. Missing test for UserBackFromChatRoom event. This handler is registered in the bloc constructor but has no test coverage.

6. Missing GetConversationOfUser failure/exception test. Only the happy path is tested. The handler has no try-catch and no else branch, if the repository throws, the bloc crashes.

7. CreateChatRoomSucessful state assertions too weak. The test uses isA<CreateChatRoomSucessful>() without verifying that the returned chatUser matches the mock. Use a predicate to check state.chatUser == mockChatUser.

Still issues in the commits:

1. You are pushing the mock generated file. test/todo_bloc_test/todo_bloc_test.mocks.dart is a Mockito-generated file. It should be added to .gitignore and regenerated via flutter pub run build_runner build. Committing generated files causes stale mocks and merge conflicts.

2. Missing UpdateToDoEvent repository failure test. There are tests for update success and update validation failure, but no test for when the repository returns Right(exception). Both AddToDoEvent and DeleteToDoEvent have this coverage. UpdateToDoEvent should too for consistency.

3. No tests for Left(false) path. In all three handlers (addToDo, updateToDo, deleteToDo), the bloc only emits a success state when l == true. If the repository returns Left(false), no state is emitted.

4. "Sucess" typo persists. In AddDoToSucessState, UpdateToDoSucessState, DeleteToDoSucessState all misspell "Success". The rename from DeleteToDoSucess → DeleteToDoSucessState is consistent with the existing pattern, but a follow-up to fix the typo across all states would be worthwhile.

5. AddDoToSucessState naming issue. "AddDoTo" vs "AddToDo" is inconsistent with the Update/Delete states. Pre-existing but worth a follow-up.

please setup your own DHIS2 and test it

Thanks @may-tas for you contribution!

Description

There are TODO comments in both lib/models/home_page_arguments.dart (line 5) and lib/screens/home_screen/home_page.dart (line 19) indicating that the current String type for high-priority alerts should be replaced with a proper HighPriorityAlert model class.

Current State

// lib/models/home_page_arguments.dart:5
// TODO: replace String with HighPriorityAlert class name (model)
List<String> highPriorityAlerts;

// lib/screens/home_screen/home_page.dart:19
// TODO: replace String with HighPriorityAlert class name (model)

Acceptance Criteria

• Create a new HighPriorityAlert model class in lib/models/
• Include relevant fields: title, message, severity, timestamp, and babyId
• Extend Equatable for value equality (following existing model patterns)
• Add fromJson() constructor and toJson() method
• Update HomePageArguments to use List<HighPriorityAlert> instead of List<String>
• Update home_page.dart to use the new model
• Verify the app builds successfully

Skills Evaluated

• Dart model class design
• Understanding of Equatable pattern
• JSON serialization/deserialization
• Tracing and updating references across files

Summary

Introduces a typed HighPriorityAlert model class to replace the ad-hoc Map<String, dynamic> / List<String> usage for high-priority alerts across the app.

Related Issue

Closes: #129

Changes

• high_priority_alert.dart (new) — HighPriorityAlert extends Equatable with fields title, message, severity (VitalSeverityType), type (VitalType), todo, timestamp, and babyId; includes fromJson() and toJson().
• home_page_arguments.dart — Updated alerts field from List<Map<String, dynamic>> to List<HighPriorityAlert>.
• home_page.dart — Updated alerts field type and replaced all map-key accesses (alerts[i]["title"]) with typed property accesses (alerts[i].title).
• main_navigator.dart — Replaced raw map literals with HighPriorityAlert(...) constructor calls.
• routing.dart — Cleaned up stale comment on the alerts pass-through.
• formatted all the files.

Testing

• All existing tests pass

Saptarshi Purkayastha (87237ea6) at 27 Feb 06:35

... and 1 more commit

Thanks @AnhDai317 for the changes. A few more areas to improve the MR:

1. The range error message is just generic invalidInput ("Invalid Input"). A user entering 100g for weight would see "Invalid Input" with no hint of the acceptable range. A message like "Weight must be between 200g and 6000g" would be far more helpful in a medical context.

2. Code style issue: Body length and head circumference range validators use single-line if without braces (lines like if (parsedValue < 20 || parsedValue > 70) return ...;). This is inconsistent with the rest of the codebase, which uses braces.

3. AddBabyParentGroup and AddBabyCaregiverGroup have requiredField validation but no localized hintText for their headings. The heading parameter for BabyWardCribNumber is still hardcoded in English: "Baby Ward Number" and "Baby Crib Number" in add_baby.dart.

4. Two consecutive VerticalSpace(height: 15) widgets remain in the form layout (before the AddBabyBirthDescription), which appears to be a leftover from the original code and should be consolidated.

5. Missing trailing newlines in all 4 ARB files. This is still outstanding from the feedback.

Saptarshi Purkayastha (10ce76af) at 26 Feb 07:29

yes, the repository updates should be in this MR since leaving callers with dead code branches is a breaking change, not a separate enhancement. The server_repository.dart already demonstrates the pattern that should be followed for the others.