TW-2710: Add settings for displaying and managing contact info visibility #2711
Conversation
|
This PR has been deployed to https://linagora.github.io/twake-on-matrix/2711 |
nqhhdev
force-pushed
the
TW-2710-settings-to-display-or-hide-contact-info
branch
from
d5bf255 to
354cd12
Compare
nqhhdev
force-pushed
the
TW-2710-settings-to-display-or-hide-contact-info
branch
from
22d687c to
30e8df2
Compare
nqhhdev
requested review from
dab246,
hoangdat and
tddang-linagora
as code owners
WalkthroughAdds a contacts visibility feature across the app: new localization keys; a SettingsContactsVisibility screen, view, controller, enums, and UI extensions; domain models UserInfoVisibility and UserInfoVisibilityRequest; repository, datasource, API, and interactor methods for getting/updating visibility; dependency injection registrations; routing for the new screen; navigation keys for testability; and new integration test robots and tests covering the settings flow. Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ 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. 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: 8
🧹 Nitpick comments (3)
lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_enum.dart (1)
20-29: Consider simplifying the logic.Both
publicandcontactsreturntrue, which can be simplified for better maintainability.Apply this diff to simplify:
bool enableDivider() { - switch (this) { - case SettingsContactsVisibilityEnum.public: - return true; - case SettingsContactsVisibilityEnum.contacts: - return true; - case SettingsContactsVisibilityEnum.private: - return false; - } + return this != SettingsContactsVisibilityEnum.private; }lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart (1)
242-242: Fix typo in method name:_buildVisibleFieldIem→_buildVisibleFieldItem- Widget _buildVisibleFieldIem({ + Widget _buildVisibleFieldItem({Also update the call site at line 152:
- return _buildVisibleFieldIem( + return _buildVisibleFieldItem(integration_test/robots/setting/settings_contacts_visibility_robot.dart (1)
11-13: Fragile finder for back button.
$(IconButton).containing($(Icon))could match anyIconButtoncontaining anIconin the widget tree, leading to flaky tests if multiple such buttons exist. Consider using a more specific key-based finder.If a key is added to the back button in the view (e.g.,
Key('contacts_visibility_back_button')), update the finder:PatrolFinder backButton() { - return $(IconButton).containing($(Icon)); + return $(Key('contacts_visibility_back_button')); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (27)
assets/l10n/intl_en.arb(1 hunks)integration_test/robots/home_robot.dart(3 hunks)integration_test/robots/setting/setting_robot.dart(3 hunks)integration_test/robots/setting/settings_contacts_visibility_robot.dart(1 hunks)integration_test/robots/setting/settings_privacy_and_security_robot.dart(1 hunks)integration_test/tests/setting/settings_contacts_visibility_test.dart(1 hunks)lib/config/go_routes/go_router.dart(2 hunks)lib/data/datasource/user_info/user_info_datasource.dart(1 hunks)lib/data/datasource_impl/user_info/user_info_datasource_impl.dart(2 hunks)lib/data/network/user_info/user_info_api.dart(2 hunks)lib/data/repository/user_info_repository_impl.dart(2 hunks)lib/di/global/get_it_initializer.dart(2 hunks)lib/domain/app_state/user_info/get_user_info_visibility_state.dart(1 hunks)lib/domain/app_state/user_info/update_user_info_visibility_state.dart(1 hunks)lib/domain/model/user_info/user_info_visibility.dart(1 hunks)lib/domain/model/user_info/user_info_visibility_request.dart(1 hunks)lib/domain/repository/user_info/user_info_repository.dart(1 hunks)lib/domain/usecase/user_info/get_user_info_visibility_interactor.dart(1 hunks)lib/domain/usecase/user_info/update_user_info_visibility_interactor.dart(1 hunks)lib/pages/settings_dashboard/settings/settings_item_builder.dart(1 hunks)lib/pages/settings_dashboard/settings/settings_view.dart(1 hunks)lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart(1 hunks)lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_enum.dart(1 hunks)lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart(1 hunks)lib/pages/settings_dashboard/settings_security/settings_security_view.dart(1 hunks)lib/widgets/avatar/bottom_navigation_avatar.dart(1 hunks)lib/widgets/layouts/enum/adaptive_destinations_enum.dart(4 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-09T06:19:59.615Z
Learnt from: tddang-linagora
Repo: linagora/twake-on-matrix PR: 2761
File: lib/pages/contacts_tab/widgets/sliver_invite_friend_button.dart:49-57
Timestamp: 2025-12-09T06:19:59.615Z
Learning: For the Twake on Matrix Flutter app (fluffychat), desktop platforms (macOS, Linux, Windows) are not supported. During reviews, assume only web and mobile targets and avoid introducing desktop-specific builds, dependencies, or platform checks. This guideline applies across Dart source files in the repository.
Applied to files:
lib/pages/settings_dashboard/settings_security/settings_security_view.dartlib/domain/usecase/user_info/get_user_info_visibility_interactor.dartlib/data/datasource/user_info/user_info_datasource.dartlib/domain/model/user_info/user_info_visibility_request.dartlib/domain/usecase/user_info/update_user_info_visibility_interactor.dartlib/domain/repository/user_info/user_info_repository.dartlib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_enum.dartlib/data/datasource_impl/user_info/user_info_datasource_impl.dartlib/domain/app_state/user_info/update_user_info_visibility_state.dartlib/di/global/get_it_initializer.dartintegration_test/robots/setting/setting_robot.dartlib/config/go_routes/go_router.dartintegration_test/robots/home_robot.dartlib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dartlib/data/repository/user_info_repository_impl.dartlib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dartlib/domain/app_state/user_info/get_user_info_visibility_state.dartintegration_test/robots/setting/settings_privacy_and_security_robot.dartlib/data/network/user_info/user_info_api.dartlib/domain/model/user_info/user_info_visibility.dartlib/widgets/layouts/enum/adaptive_destinations_enum.dartintegration_test/robots/setting/settings_contacts_visibility_robot.dartlib/widgets/avatar/bottom_navigation_avatar.dartlib/pages/settings_dashboard/settings/settings_item_builder.dartintegration_test/tests/setting/settings_contacts_visibility_test.dartlib/pages/settings_dashboard/settings/settings_view.dart
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Analyze code
- GitHub Check: Widget test
- GitHub Check: Deploy preview versions on pull requests
🔇 Additional comments (27)
lib/pages/settings_dashboard/settings/settings_item_builder.dart (1)
42-42: LGTM!The key forwarding to
TwakeInkWellis correct and will enable proper widget identification for testing purposes.lib/config/go_routes/go_router.dart (1)
452-459: LGTM!The route configuration follows the established patterns in the codebase, is properly nested under the security settings group, and includes appropriate redirect logic.
lib/pages/settings_dashboard/settings/settings_view.dart (1)
184-184: LGTM!Using
Key(item.name)provides stable, unique keys for each settings item, which is beneficial for testing and widget identification.lib/pages/settings_dashboard/settings_security/settings_security_view.dart (1)
63-77: LGTM!The contacts visibility settings item is properly implemented following the established patterns in the security settings view. The inclusion of a test key and proper navigation setup is good practice.
lib/widgets/layouts/enum/adaptive_destinations_enum.dart (1)
22-22: LGTM!Adding keys to navigation destinations improves testability without affecting functionality. The key naming convention is consistent and follows Flutter best practices.
Also applies to: 35-35, 48-48, 94-94, 99-99
assets/l10n/intl_en.arb (1)
3493-3494: Fix grammatical errors in user-facing strings.The localization keys contain typos:
- Line 3493: "youNumberIsVisibleAccordingToTheSettingAbove" → should be "Your number" or "Your phone number"
- Line 3494: "youEmailIsVisibleAccordingToTheSettingAbove" → should be "Your email"
Apply this diff to fix the strings:
- "youNumberIsVisibleAccordingToTheSettingAbove": "Your number is visible according to the setting above", + "youNumberIsVisibleAccordingToTheSettingAbove": "Your phone number is visible according to the setting above", "@youNumberIsVisibleAccordingToTheSettingAbove": {}, - "youEmailIsVisibleAccordingToTheSettingAbove": "Your email is visible according to the setting above", + "youEmailIsVisibleAccordingToTheSettingAbove": "Your email address is visible according to the setting above",Likely an incorrect or invalid review comment.
lib/data/repository/user_info_repository_impl.dart (1)
16-30: No action needed—error handling is properly implemented across the data and domain layers.The datasource and use-case layers already handle exceptions correctly. The API layer (UserInfoApi) uses
.onError()to re-throw errors with proper type preservation, and both interactors (GetUserInfoVisibilityInteractor and UpdateUserInfoVisibilityInteractor) wrap repository calls in try-catch blocks, converting exceptions to Either<Failure, Success> using the dartz pattern. This is a standard clean architecture error handling approach where errors propagate from the API through the datasource and repository, then are caught and transformed at the use-case level.Likely an incorrect or invalid review comment.
integration_test/robots/setting/setting_robot.dart (1)
6-6: LGTM! Improved test robustness with Key-based finder.The rename from "privateAndSecuritySetting" to "privacyAndSecuritySetting" fixes the typo, and switching from a text-based finder to a Key-based finder makes the test more robust against localization changes.
Also applies to: 24-26, 58-58
integration_test/robots/home_robot.dart (1)
2-2: LGTM! Key-based finder improves test maintainability.The switch to a Key-based finder for the settings tab makes the test more resilient to UI text changes and localization.
Also applies to: 21-21, 40-41
lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_enum.dart (1)
9-18: LGTM! Localized title mapping is correct.The title method properly maps each enum value to its localized string.
lib/domain/repository/user_info/user_info_repository.dart (1)
2-3: LGTM! Clean interface extension.The new methods for user visibility management are well-defined and follow the existing repository pattern.
Also applies to: 8-13
lib/data/datasource_impl/user_info/user_info_datasource_impl.dart (1)
5-6: LGTM! Consistent datasource implementation.The new methods follow the existing delegation pattern to the API layer.
Also applies to: 17-30
lib/data/network/user_info/user_info_api.dart (2)
46-69: Verify whether visibility data should be cached.The
getUserInfomethod usesMatrixDioCacheInterceptorto cache responses, butgetUserVisibilitydoes not. If visibility settings can change frequently and should always reflect the latest state, omitting the cache is correct. However, if caching would improve performance without staleness concerns, consider adding it.
71-98: LGTM! Update method follows the established pattern.The implementation correctly uses POST for updating visibility settings and maintains consistent error handling with other API methods.
integration_test/tests/setting/settings_contacts_visibility_test.dart (1)
6-66: LGTM! Well-structured integration tests.The tests clearly verify the presence of each visibility option and related UI elements. The separation into distinct tests makes it easy to identify which specific feature fails if a test breaks.
lib/domain/usecase/user_info/update_user_info_visibility_interactor.dart (1)
12-28: LGTM! Standard interactor pattern correctly implemented.The interactor follows the established pattern in the codebase with appropriate state emissions and error handling.
lib/di/global/get_it_initializer.dart (1)
138-139: DI wiring for visibility interactors is consistentThe new imports and
registerFactorybindings forGetUserInfoVisibilityInteractorandUpdateUserInfoVisibilityInteractorfollow the existing interactor pattern and look correct.Also applies to: 539-541
integration_test/robots/setting/settings_privacy_and_security_robot.dart (1)
1-18: Robot for navigating to Contacts Visibility screen looks goodThe finder key and the
openContactVisibilitySetting()flow (tap +waitUntilVisibleonSettingsContactsVisibilityView) align with existing robot patterns and should be reliable for integration tests.lib/domain/usecase/user_info/get_user_info_visibility_interactor.dart (1)
1-24: GetUserInfoVisibility interactor follows existing patternThe interactor correctly emits
GettingUserInfoVisibilityfollowed by eitherGetUserInfoVisibilitySuccessorGetUserInfoVisibilityFailure, and usesUserInfoRepository.getUserVisibilityvia DI. This is consistent with other interactors and looks fine.lib/data/datasource/user_info/user_info_datasource.dart (1)
2-13: UserInfoDatasource visibility API shape is appropriateExtending the contract with
getUserVisibilityandupdateUserInfoVisibilityusingUserInfoVisibility/UserInfoVisibilityRequestmatches the new use cases and keeps the abstraction clean.lib/domain/model/user_info/user_info_visibility_request.dart (1)
1-29: UserInfoVisibilityRequest model and JSON mapping look solidThe model cleanly represents the payload with optional
visibilityandvisible_fields, uses json_serializable correctly, and defines value equality viaEquatableMixin. No issues from a domain or serialization perspective.lib/domain/app_state/user_info/update_user_info_visibility_state.dart (1)
1-26: Update visibility state classes are consistent with existing patterns
UpdatingUserInfoVisibility,UpdateUserInfoVisibilitySuccess, andUpdateUserInfoVisibilityFailureline up with the get-visibility states and the interactor flow; equality viapropsis correctly wired.lib/domain/app_state/user_info/get_user_info_visibility_state.dart (1)
1-26: Get visibility state classes are well-aligned with the interactor
GettingUserInfoVisibility,GetUserInfoVisibilitySuccess, andGetUserInfoVisibilityFailureprovide the expected loading/success/failure trio and match how the interactor emits states. No changes needed here.lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart (2)
76-99: OuterValueListenableBuilderappears unused.The
statefromgetUserInfoVisibilityNotifieris captured but never referenced in the inner builder. If this notifier is only needed for initial data loading, consider whether this builder is necessary here or if the logic should be restructured.Please verify if
getUserInfoVisibilityNotifieris intended to trigger rebuilds here. If not, consider removing the outer builder to simplify the widget tree.
11-14: LGTM on the overall structure and widget key usage.Good practice using
Keyfor visibility options and fields—this aids testability and integration test automation. The controller-view separation is clean.Also applies to: 182-240, 242-316
integration_test/robots/setting/settings_contacts_visibility_robot.dart (2)
16-79: LGTM on finder organization and naming.The finders are well-organized with clear naming conventions, and the key-based approach using enum names ensures consistency with the view's widget keys.
82-105: LGTM on action methods.The action methods properly await taps and use
waitUntilVisibleorpumpAndSettleto ensure UI stability before proceeding.Also applies to: 158-160
...pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart
Show resolved
Hide resolved
...pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart
Show resolved
Hide resolved
lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart
Show resolved
Hide resolved
lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart
Show resolved
Hide resolved
lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart
Show resolved
Hide resolved
|
Looks like the rabbit had very valuable comments |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart (1)
214-218: Consider callingsuper.initState()first.Flutter convention is to call
super.initState()before performing initialization logic. While this works, reordering improves consistency with Flutter patterns.@override void initState() { + super.initState(); initialGetUserInfoVisibility(); - super.initState(); }integration_test/robots/setting/settings_contacts_visibility_robot.dart (1)
11-13: Consider using a more specific finder forbackButton().
$(IconButton).containing($(Icon))is generic and could match multiple widgets if the screen has more than one IconButton. Consider using a Key or semantic identifier for more reliable test targeting.PatrolFinder backButton() { - return $(IconButton).containing($(Icon)); + return $(Key('settings_contacts_visibility_back_button')); }This requires adding a corresponding Key to the back button widget in the view.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
integration_test/robots/setting/settings_contacts_visibility_robot.dart(1 hunks)lib/domain/model/user_info/user_info_visibility.dart(1 hunks)lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart(1 hunks)lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart(1 hunks)lib/presentation/extensions/settings/user_info_visibility_extension.dart(1 hunks)lib/widgets/avatar/bottom_navigation_avatar.dart(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility_view.dart
- lib/domain/model/user_info/user_info_visibility.dart
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-12-10T04:59:56.814Z
Learnt from: chibenwa
Repo: linagora/twake-on-matrix PR: 2711
File: lib/domain/model/user_info/user_info_visibility.dart:8-38
Timestamp: 2025-12-10T04:59:56.814Z
Learning: In the fluffychat codebase, domain models (in lib/domain/model/) should remain UI-agnostic and not contain UI-related methods that depend on BuildContext or L10n. UI presentation logic for domain enums should be implemented as extensions in the presentation layer (e.g., lib/presentation/extensions/).
Applied to files:
lib/presentation/extensions/settings/user_info_visibility_extension.dart
📚 Learning: 2025-12-09T06:19:59.615Z
Learnt from: tddang-linagora
Repo: linagora/twake-on-matrix PR: 2761
File: lib/pages/contacts_tab/widgets/sliver_invite_friend_button.dart:49-57
Timestamp: 2025-12-09T06:19:59.615Z
Learning: For the Twake on Matrix Flutter app (fluffychat), desktop platforms (macOS, Linux, Windows) are not supported. During reviews, assume only web and mobile targets and avoid introducing desktop-specific builds, dependencies, or platform checks. This guideline applies across Dart source files in the repository.
Applied to files:
lib/presentation/extensions/settings/user_info_visibility_extension.dartlib/widgets/avatar/bottom_navigation_avatar.dartlib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dartintegration_test/robots/setting/settings_contacts_visibility_robot.dart
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Deploy preview versions on pull requests
- GitHub Check: Widget test
- GitHub Check: Analyze code
🔇 Additional comments (8)
lib/widgets/avatar/bottom_navigation_avatar.dart (1)
16-16: LGTM!The blank line improves readability by providing visual separation between the constructor and the build method.
lib/presentation/extensions/settings/user_info_visibility_extension.dart (1)
1-27: LGTM! Proper separation of UI logic from domain model.The extension correctly places UI-related methods (localized titles, subtitles, divider logic) in the presentation layer rather than in the domain model, following the established pattern. Based on learnings, this aligns with the codebase convention that domain models in
lib/domain/model/remain UI-agnostic.lib/pages/settings_dashboard/settings_contacts_visibility/settings_contacts_visibility.dart (4)
220-228: Past review issues addressed: dispose properly cleans up resources.The dispose method now correctly:
- Cancels both
getUserInfoVisibilityStreamSubandupdateUserInfoVisibilityStreamSub- Disposes all four
ValueNotifierinstancesThis prevents memory leaks and dangling subscriptions that could fire after widget disposal.
126-135: Past review issue addressed: null check guards against uninitialized client.The null check for
client.userIDis now consistent betweenupdateUserInfoVisibility()andinitialGetUserInfoVisibility(), preventing potential null pointer exceptions if the client becomes uninitialized.
155-165: Past review issue addressed:selectedVisibleFieldNotifiernow stays in sync.The success handler correctly updates both
selectedVisibilityOptionNotifierandselectedVisibleFieldNotifierwith backend response data, ensuring subsequent toggles compute from current state.
136-137: Good practice: cancelling previous subscription before starting new one.This prevents overlapping stream listeners and ensures only one update operation is in progress at a time.
integration_test/robots/setting/settings_contacts_visibility_robot.dart (2)
113-131: Past review issue addressed: state-check methods now work correctly.The helper methods now directly return the
.existsboolean value instead of wrapping in try/catch blocks that always returnedtrue.
81-110: LGTM! Actions follow proper async testing patterns.The action methods correctly use
waitUntilVisibleafter selection taps to ensure state transitions complete, andpumpAndSettlefor toggle operations. This approach prevents flaky tests from timing issues.
| ); | ||
| } | ||
|
|
||
| Widget _buildVisibleFieldIem({ |
There was a problem hiding this comment.
| Widget _buildVisibleFieldIem({ | |
| Widget _buildVisibleFieldItem({ |
| Padding( | ||
| padding: const EdgeInsets.only( | ||
| left: 8, | ||
| right: 16, | ||
| ), | ||
| child: SizedBox( | ||
| width: 24, | ||
| height: 24, | ||
| child: isSelected | ||
| ? Icon( | ||
| key: Key('visible_field_option_selected_${option.name}'), | ||
| Icons.check, | ||
| color: LinagoraSysColors.material().primary, | ||
| size: 24, | ||
| ) | ||
| : null, | ||
| ), | ||
| ), |
There was a problem hiding this comment.
| Padding( | |
| padding: const EdgeInsets.only( | |
| left: 8, | |
| right: 16, | |
| ), | |
| child: SizedBox( | |
| width: 24, | |
| height: 24, | |
| child: isSelected | |
| ? Icon( | |
| key: Key('visible_field_option_selected_${option.name}'), | |
| Icons.check, | |
| color: LinagoraSysColors.material().primary, | |
| size: 24, | |
| ) | |
| : null, | |
| ), | |
| ), | |
| Container( | |
| padding: const EdgeInsets.only( | |
| left: 8, | |
| right: 16, | |
| ), | |
| width: 24, | |
| height: 24, | |
| child: isSelected | |
| ? Icon( | |
| key: Key('visible_field_option_selected_${option.name}'), | |
| Icons.check, | |
| color: LinagoraSysColors.material().primary, | |
| size: 24, | |
| ) | |
| : null, | |
| ), |
There was a problem hiding this comment.
For lists or frequently rebuilt widgets, the performance difference compounds. SizedBox is specifically optimized for size constraints, while Container is a convenience wrapper that does more work under the hood.
https://claude.ai/share/bedde466-c0a5-48b3-b2e5-3497dfe19b5b
| Padding( | ||
| padding: const EdgeInsets.only( | ||
| left: 8, | ||
| right: 16, | ||
| ), | ||
| child: SizedBox( | ||
| width: 24, | ||
| height: 24, | ||
| child: isSelected | ||
| ? Icon( | ||
| key: Key('visibility_option_selected_${option.name}'), | ||
| Icons.check, | ||
| color: LinagoraSysColors.material().primary, | ||
| size: 24, | ||
| ) | ||
| : null, | ||
| ), | ||
| ), |
There was a problem hiding this comment.
Multiple ValueListenableBuilder with controller.selectedVisibleFieldNotifier. Should they be combined?
| if (option == selectedVisibilityOptionNotifier.value) { | ||
| return; | ||
| } | ||
| switch (option) { |
There was a problem hiding this comment.
why visibleFields: for each option is not consistent?
|
Ticket
Resolved
Attach screenshots or videos demonstrating the changes
Screen.Recording.2025-11-26.at.11.02.19.mov
Summary by CodeRabbit
New Features
Localization
Navigation / UI
Tests
✏️ Tip: You can customize this high-level summary in your review settings.