Make user-created orders also appear in the order book, not just in My Trades #129
Conversation
WalkthroughThe changes introduce session-aware labeling and navigation for order list items, update order filtering logic by removing session-based exclusions, add new localization strings for session-specific labels in English, Spanish, and Italian, modify session retrieval logic in the session provider, and update the Flutter workflow to use version 3.32.5. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant OrderListItem
participant SessionProvider
participant Navigator
User->>OrderListItem: Tap order item
OrderListItem->>SessionProvider: Check for session with orderId
alt Session exists
OrderListItem->>Navigator: Navigate to /trade_detail/{orderId}
else No session
alt Order type is BUYING
OrderListItem->>Navigator: Navigate to /take_buy/{orderId}
else Order type is SELLING
OrderListItem->>Navigator: Navigate to /take_sell/{orderId}
end
end
Estimated code review effort2 (~15 minutes) Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
📓 Path-based instructions (2)lib/**/*.dart📄 CodeRabbit Inference Engine (CLAUDE.md)
Files:
**/*.dart📄 CodeRabbit Inference Engine (CLAUDE.md)
Files:
🧠 Learnings (1)lib/shared/providers/session_notifier_provider.dart (8)Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: chebizarro Learnt from: chebizarro Learnt from: CR Learnt from: chebizarro Learnt from: CR 🧰 Additional context used📓 Path-based instructions (2)lib/**/*.dart📄 CodeRabbit Inference Engine (CLAUDE.md)
Files:
**/*.dart📄 CodeRabbit Inference Engine (CLAUDE.md)
Files:
🧠 Learnings (1)lib/shared/providers/session_notifier_provider.dart (8)Learnt from: CR Learnt from: CR Learnt from: CR Learnt from: chebizarro Learnt from: chebizarro Learnt from: CR Learnt from: chebizarro Learnt from: CR 🔇 Additional comments (1)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
CodeRabbit Configuration File (
|
Catrya
left a comment
Catrya
left a comment
There was a problem hiding this comment.
Hi @chebizarro Sometimes when I create an order it doesn't have the label "you are selling" or "you are buying", and when I open the order I get an error.
But if I close and reopen the app it works fine and the error doesn't appear.
…xe: Add invoice text to seller #50
1. Added share_plus dependency to pubspec.yaml and ran flutter pub get
2. Updated pay_lightning_invoice_widget.dart (around lines 57-61):
- Removed the Text widget displaying the raw lightning invoice
- Replaced it with a Row containing two buttons:
- Copy button: Copies the invoice to clipboard and shows a snackbar notification
- Share button: Uses the native share functionality to share the invoice with other apps
- Removed the duplicate copy button that was previously below
- Styled both buttons consistently with the existing design (green background, rounded
corners, icons)
3. Added required import for share_plus/share_plus.dart
…l button UI (fixes Show Cancel and Dispute buttons when counterparty opens a cooperative cancellation #126)
- Add complete Spanish translations (intl_es.arb) with 120+ keys - Update English and Italian ARB files with new UI strings - Replace hardcoded English strings with localized versions in: - Authentication screens (login, register, welcome) - Home screen (filters, empty states, navigation) - Trading screens (status labels, actions, details) - UI components and widgets - Add automatic Spanish locale detection and fallback logic - Include comprehensive language addition documentation - Remove deprecated action_localizations.dart references All user-facing text now properly supports English, Spanish, and Italian with automatic device language detection and graceful fallbacks.
- Added 40+ new translation keys to support all remaining hardcoded strings - Localized BUY/SELL buttons, order creation screens, and form validation - Translated drawer menu items (Account, Settings, About, Walkthrough) - Updated settings screen with complete Spanish localization - Localized about screen with all instance details and app information - Enhanced walkthrough screens with Spanish translations - Fixed order list items to display localized timestamps and ratings - Removed debug locale logging as requested - Updated all ARB files (English, Spanish, Italian) with new translation keys - Resolved compilation errors and optimized localization method calls - Successfully tested build compilation
…ardcoded strings
This commit removes all remaining hardcoded English strings throughout the Flutter app and replaces them with proper localization keys, providing comprehensive Spanish translation support.
## Major Changes:
### Order Creation Forms (55+ strings localized)
- Amount entry forms with validation messages and hints
- Payment method selection dialogs and custom input fields
- Premium slider with tooltips and explanations
- Error handling and user feedback messages
### Account Management Screen (15+ strings localized)
- Secret word management and restoration instructions
- Privacy settings and controls
- Trade index counters and explanations
- Key import/export functionality with success/error messages
### Chat System (8+ strings localized)
- Chat room headers and empty state messages
- Message input placeholders and conversation info
- User handle display and shared key information
- Navigation elements ("BACK", "CHAT" labels)
### Trade Detail Actions (12+ strings localized)
- All action buttons: PAY INVOICE, ADD INVOICE, FIAT SENT, DISPUTE, RELEASE, TAKE SELL/BUY
- Order ID copy confirmation and trade cancellation dialogs
- Status messages and user instructions
### Technical Improvements:
- Fixed duplicate ARB keys by renaming button-specific keys (payInvoiceButton vs payInvoice)
- Added proper BuildContext parameters to methods requiring localization
- Resolved compilation errors with const widgets containing dynamic localization calls
- Updated documentation with comprehensive localization coverage details
- Added README reference to ADDING_NEW_LANGUAGE.md guide
### Files Modified:
- lib/l10n/intl_en.arb - Added 45+ new English localization keys
- lib/l10n/intl_es.arb - Added 45+ new Spanish translations
- lib/l10n/intl_it.arb - Added 45+ new Italian translations
- 9 Flutter widget/screen files updated with S.of(context) calls
- README.md and ADDING_NEW_LANGUAGE.md documentation enhanced
### Testing:
- Build compilation verified successfully
- All hardcoded strings replaced with localized equivalents
- No remaining English text in Spanish locale areas
The app now provides complete Spanish localization covering all user-facing strings, from basic navigation to complex order creation flows and account management features.
Fixed multiple duplicate localization keys in intl_es.arb that were causing potential conflicts in the Spanish translation system: Removed duplicates for: - addRelay, cancel, cancelTrade, chat, confirm - creatingNewOrder, discoverSecurePlatform, dispute - done, easyOnboarding, enterSatsAmountBuy, enterSatsAmountSell - fiatSent, guidedWalkthroughSimple, orderIdCopied - seamlessPeerToPeer, settings, skip, tradeWithConfidence - welcomeToMostroMobile This ensures clean localization file structure and prevents any translation key conflicts. Build verification completed successfully.
Fixed multiple duplicate localization keys in intl_it.arb that were repeating entries already defined earlier in the file. Preserved original entries from lines 59-158 and removed duplicates from lines 159-197. Removed duplicates for: - addRelay, cancel, cancelTrade, chat, confirm, creatingNewOrder - discoverSecurePlatform, dispute, done, easyOnboarding - enterSatsAmountBuy, enterSatsAmountSell, fiatSent - guidedWalkthroughSimple, orderIdCopied, seamlessPeerToPeer - settings, skip, tradeWithConfidence, welcomeToMostroMobile This ensures clean Italian localization file structure with each key appearing only once. JSON validation and build compilation verified successfully.
Fixed duplicate localization keys in intl_en.arb that were conflicting with earlier definitions, specifically addressing: Lines 159-161: Removed duplicate entries for: - creatingNewOrder (conflicted with line 81) - enterSatsAmountBuy (conflicted with line 82) - enterSatsAmountSell (conflicted with line 83) Line 169: Removed duplicate entry for: - settings (conflicted with line 93) Lines 189-197: Removed duplicate entries for: - welcomeToMostroMobile (conflicted with line 111) - discoverSecurePlatform, easyOnboarding, guidedWalkthroughSimple - tradeWithConfidence, seamlessPeerToPeer (conflicted with lines 112-116) - skip, done (conflicted with lines 117-118) - addRelay (conflicted with line 99) Also removed additional duplicate keys throughout the file: - cancel, confirm, chat, fiatSent, dispute, cancelTrade, orderIdCopied This ensures Flutter's localization generation works correctly by preventing key overwrites and maintaining clean ARB structure. All original key definitions from lines 81-118 are preserved.
…ings - Add 73 new localization keys to English, Spanish, and Italian ARB files - Replace all hardcoded strings in 8 critical widget files: * Currency selection and order creation screens * Payment and invoice handling widgets * Trade detail and rating screens * Navigation and button labels - Add proper ARB metadata for parameterized strings - Fix type conversion issue in home_screen.dart (offersCount) - Ensure all localization method calls have proper BuildContext - Validate JSON syntax and build compilation Now Spanish users see native translations like: - "Selecciona la moneda fiat..." → "Select the fiat currency..." - "CERRAR/TOMAR" → "CLOSE/TAKE" - "Pagar Factura Lightning" → "Pay Lightning Invoice" Italian users see native translations like: - "Seleziona la valuta fiat..." → "Select the fiat currency..." - "CHIUDI/PRENDI" → "CLOSE/TAKE" - "Paga Fattura Lightning" → "Pay Lightning Invoice"
Fix timeLeft showing function closure instead of proper text by changing from string interpolation to proper method call with parameter.
Changed: '${S.of(context)\!.timeLeft}: ${time}'
To: S.of(context)\!.timeLeft(time)
- Add timeAgoWithLocale method to NostrEvent extension that accepts locale parameter - Update order list item to use app's current locale instead of device locale - Ensure Spanish "hace X horas" displays correctly instead of English "hours ago" - Modify _timeAgo method to support locale parameter with Spanish fallback Resolves issue where timeago package was using device locale instead of app locale.
- Remove unused imports and fields (dart:ui, flutter/material, _settings, _formatPaymentMethods) - Replace deprecated withOpacity() with withValues(alpha:) across all files - Replace deprecated WillPopScope with PopScope in custom_drawer_overlay.dart - Add proper mounted checks for BuildContext usage after async operations - Fix constructor immutability in WalkthroughScreen - Remove duplicate ignore directive in test mocks - Add ignore comments for unused test variables Reduces Flutter analyze issues from 54 to 2 (remaining are false positives with proper mounted checks)
Add ignore comments for properly guarded BuildContext usage in pay_lightning_invoice_widget.dart. These warnings were false positives as the code already has proper mounted checks. Now achieves zero Flutter analyze issues.
Add detailed project documentation including: - Architecture overview and development commands - Internationalization system and best practices - Code quality standards and git workflow - Recent work context and key file locations - User preferences and working style guidelines This file provides complete context for future development sessions.
![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 (6)
lib/features/auth/notifiers/auth_notifier.dart (1)
37-39: Good practice: Removing debug print statements from production code.The removal of debug print statements from the catch block is a positive change that prevents log clutter and potential information leakage in production. The essential error handling is preserved by setting the state to
AuthFailure.Consider implementing proper logging with different levels (debug, info, error) that can be controlled via build configurations if debugging information is needed during development.
lib/data/models/order.dart (1)
182-204: Consider expanding the copyWith method for better maintainability.The current implementation is functionally correct and properly copies all fields. However, the method is quite restrictive as it only allows updating the
buyerInvoicefield.While this may meet the current requirements, consider implementing a more comprehensive
copyWithmethod that supports updating any field for better maintainability and consistency with typical Dart patterns.-Order copyWith({String? buyerInvoice}) { +Order copyWith({ + String? id, + OrderType? kind, + Status? status, + int? amount, + String? fiatCode, + int? minAmount, + int? maxAmount, + int? fiatAmount, + String? paymentMethod, + int? premium, + String? masterBuyerPubkey, + String? masterSellerPubkey, + String? buyerTradePubkey, + String? sellerTradePubkey, + String? buyerInvoice, + int? createdAt, + int? expiresAt, + int? buyerToken, + int? sellerToken, +}) { return Order( - id: id, - kind: kind, - status: status, - amount: amount, - fiatCode: fiatCode, - minAmount: minAmount, - maxAmount: maxAmount, - fiatAmount: fiatAmount, - paymentMethod: paymentMethod, - premium: premium, - masterBuyerPubkey: masterBuyerPubkey, - masterSellerPubkey: masterSellerPubkey, - buyerTradePubkey: buyerTradePubkey, - sellerTradePubkey: sellerTradePubkey, + id: id ?? this.id, + kind: kind ?? this.kind, + status: status ?? this.status, + amount: amount ?? this.amount, + fiatCode: fiatCode ?? this.fiatCode, + minAmount: minAmount ?? this.minAmount, + maxAmount: maxAmount ?? this.maxAmount, + fiatAmount: fiatAmount ?? this.fiatAmount, + paymentMethod: paymentMethod ?? this.paymentMethod, + premium: premium ?? this.premium, + masterBuyerPubkey: masterBuyerPubkey ?? this.masterBuyerPubkey, + masterSellerPubkey: masterSellerPubkey ?? this.masterSellerPubkey, + buyerTradePubkey: buyerTradePubkey ?? this.buyerTradePubkey, + sellerTradePubkey: sellerTradePubkey ?? this.sellerTradePubkey, buyerInvoice: buyerInvoice ?? this.buyerInvoice, - buyerToken: buyerToken, - sellerToken: sellerToken, - expiresAt: expiresAt, - createdAt: createdAt, + createdAt: createdAt ?? this.createdAt, + expiresAt: expiresAt ?? this.expiresAt, + buyerToken: buyerToken ?? this.buyerToken, + sellerToken: sellerToken ?? this.sellerToken, ); }lib/shared/widgets/notification_listener_widget.dart (1)
19-19: Consider using more specific localized strings.The internationalization changes are good, but using
S.of(context)!.erroras both the dialog title and fallback text for actions might not provide the best user experience. Consider using more specific localized strings likeS.of(context)!.actionRequiredfor the dialog title andS.of(context)!.unknownActionfor the fallback text.- title: Text(S.of(context)!.error), + title: Text(S.of(context)!.actionRequired),And for the action fallback:
- content: Text(next.action?.toString() ?? S.of(context)!.error)), + content: Text(next.action?.toString() ?? S.of(context)!.unknownAction)),Also applies to: 27-28, 32-32, 39-39
lib/features/trades/widgets/mostro_message_detail_widget.dart (1)
176-176: Consider a more user-friendly fallback message.While the clarifying comment is helpful, the fallback message exposes internal implementation details to users. Consider using a localized, user-friendly message instead:
- return 'No message found for action ${tradeState.action}'; // This is a fallback message for developers + return S.of(context)!.unknownAction; // User-friendly fallbackThis would provide a better user experience while still allowing developers to identify missing action handlers through logging or debugging tools.
ADDING_NEW_LANGUAGE.md (1)
33-33: Minor formatting improvements for consistency.The documentation has some minor style issues that could be cleaned up:
-``` +```text lib/ -### For Research Tasks: +### For Research Tasks -### For Implementation Tasks: +### For Implementation Tasks -### Critical Requirements: +### Critical Requirements -### Example Workflow: +### Example Workflow -``` +```bash 1. Read intl_en.arb to understand structureAlso applies to: 289-289, 294-294, 301-301, 308-309
CLAUDE.md (1)
66-66: Fix grammar issues in the development guidelines.The line contains two grammar issues that should be corrected for professional documentation:
- Missing preposition - should be "side effect free" (open compound)
- The hyphenated "side-effect" should be "side effect" according to standard usage
-- Keep UI code declarative and side-effect free +- Keep UI code declarative and side effect free
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
lib/generated/action_localizations.dartis excluded by!**/generated/**pubspec.lockis excluded by!**/*.lock
📒 Files selected for processing (63)
.github/workflows/flutter.yml(1 hunks).gitignore(2 hunks)ADDING_NEW_LANGUAGE.md(1 hunks)CLAUDE.md(1 hunks)README.md(1 hunks)lib/background/background_service.dart(1 hunks)lib/background/desktop_background_service.dart(1 hunks)lib/core/app.dart(2 hunks)lib/core/app_theme.dart(2 hunks)lib/data/models/nostr_event.dart(2 hunks)lib/data/models/order.dart(1 hunks)lib/data/repositories/auth_repository.dart(0 hunks)lib/data/repositories/event_storage.dart(1 hunks)lib/features/auth/notifiers/auth_notifier.dart(1 hunks)lib/features/auth/screens/login_screen.dart(4 hunks)lib/features/auth/screens/register_screen.dart(10 hunks)lib/features/auth/screens/welcome_screen.dart(4 hunks)lib/features/chat/screens/chat_room_screen.dart(4 hunks)lib/features/chat/screens/chat_rooms_list.dart(3 hunks)lib/features/home/screens/home_screen.dart(7 hunks)lib/features/home/widgets/order_list_item.dart(10 hunks)lib/features/key_manager/key_management_screen.dart(10 hunks)lib/features/order/models/order_state.dart(2 hunks)lib/features/order/notfiers/order_notifier.dart(0 hunks)lib/features/order/screens/add_lightning_invoice_screen.dart(2 hunks)lib/features/order/screens/add_order_screen.dart(5 hunks)lib/features/order/screens/pay_lightning_invoice_screen.dart(2 hunks)lib/features/order/screens/take_order_screen.dart(11 hunks)lib/features/order/widgets/amount_section.dart(3 hunks)lib/features/order/widgets/currency_section.dart(5 hunks)lib/features/order/widgets/form_section.dart(2 hunks)lib/features/order/widgets/lightning_address_section.dart(1 hunks)lib/features/order/widgets/payment_methods_section.dart(6 hunks)lib/features/order/widgets/premium_section.dart(2 hunks)lib/features/order/widgets/price_type_section.dart(2 hunks)lib/features/rate/rate_counterpart_screen.dart(3 hunks)lib/features/settings/about_screen.dart(9 hunks)lib/features/settings/settings_screen.dart(7 hunks)lib/features/trades/screens/trade_detail_screen.dart(23 hunks)lib/features/trades/screens/trades_screen.dart(6 hunks)lib/features/trades/widgets/mostro_message_detail_widget.dart(1 hunks)lib/features/trades/widgets/trades_list_item.dart(5 hunks)lib/features/walkthrough/screens/walkthrough_screen.dart(3 hunks)lib/l10n/intl_en.arb(1 hunks)lib/l10n/intl_es.arb(1 hunks)lib/l10n/intl_it.arb(1 hunks)lib/main.dart(3 hunks)lib/shared/widgets/add_lightning_invoice_widget.dart(5 hunks)lib/shared/widgets/add_order_button.dart(3 hunks)lib/shared/widgets/bottom_nav_bar.dart(4 hunks)lib/shared/widgets/custom_drawer_overlay.dart(4 hunks)lib/shared/widgets/mostro_app_bar.dart(1 hunks)lib/shared/widgets/mostro_reactive_button.dart(1 hunks)lib/shared/widgets/notification_listener_widget.dart(1 hunks)lib/shared/widgets/pay_lightning_invoice_widget.dart(6 hunks)linux/flutter/generated_plugin_registrant.cc(0 hunks)linux/flutter/generated_plugins.cmake(0 hunks)macos/Flutter/GeneratedPluginRegistrant.swift(0 hunks)pubspec.yaml(1 hunks)test/mocks.mocks.dart(2 hunks)test/notifiers/take_order_notifier_test.dart(4 hunks)windows/flutter/generated_plugin_registrant.cc(0 hunks)windows/flutter/generated_plugins.cmake(0 hunks)
💤 Files with no reviewable changes (7)
- lib/features/order/notfiers/order_notifier.dart
- lib/data/repositories/auth_repository.dart
- linux/flutter/generated_plugin_registrant.cc
- windows/flutter/generated_plugin_registrant.cc
- macos/Flutter/GeneratedPluginRegistrant.swift
- linux/flutter/generated_plugins.cmake
- windows/flutter/generated_plugins.cmake
✅ Files skipped from review due to trivial changes (26)
- README.md
- lib/features/order/screens/pay_lightning_invoice_screen.dart
- lib/data/repositories/event_storage.dart
- lib/features/settings/settings_screen.dart
- lib/features/order/widgets/form_section.dart
- lib/features/order/widgets/premium_section.dart
- lib/features/auth/screens/login_screen.dart
- lib/shared/widgets/add_lightning_invoice_widget.dart
- lib/features/order/widgets/amount_section.dart
- lib/features/order/widgets/currency_section.dart
- lib/features/auth/screens/register_screen.dart
- lib/core/app_theme.dart
- lib/features/order/widgets/price_type_section.dart
- lib/features/auth/screens/welcome_screen.dart
- lib/shared/widgets/add_order_button.dart
- lib/features/order/widgets/lightning_address_section.dart
- lib/features/order/screens/add_order_screen.dart
- lib/features/order/widgets/payment_methods_section.dart
- lib/features/trades/screens/trades_screen.dart
- lib/features/key_manager/key_management_screen.dart
- lib/features/chat/screens/chat_rooms_list.dart
- lib/features/chat/screens/chat_room_screen.dart
- lib/features/settings/about_screen.dart
- .gitignore
- test/mocks.mocks.dart
- lib/features/order/screens/take_order_screen.dart
🚧 Files skipped from review as they are similar to previous changes (1)
- lib/features/home/widgets/order_list_item.dart
🧰 Additional context used
🧠 Learnings (12)
lib/shared/widgets/mostro_reactive_button.dart (4)
Learnt from: chebizarro
PR: MostroP2P/mobile#127
File: lib/features/order/notfiers/abstract_mostro_notifier.dart:45-54
Timestamp: 2025-06-26T15:03:23.529Z
Learning: In AbstractMostroNotifier, state updates occur for all messages regardless of timestamp to hydrate the OrderNotifier from MostroStorage during sync, while handleEvent is only called for recent messages (within 60 seconds) to prevent re-triggering side effects like notifications and navigation for previously handled messages. This design prevents displaying stale notifications when the app is reopened or brought to the foreground.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/shared/widgets/mostro_reactive_button.dart:22-32
Timestamp: 2025-05-08T15:39:07.322Z
Learning: In the Mostro Mobile codebase, WidgetStateProperty is used instead of the deprecated MaterialStateProperty for styling buttons with state-dependent properties.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
test/notifiers/take_order_notifier_test.dart (1)
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
lib/shared/widgets/notification_listener_widget.dart (2)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, Riverpod code generation is used with `@Riverpod` annotations. Providers like `eventStorageProvider` are generated in `.g.dart` files from annotated functions in the main provider files. These providers are accessible by importing the main provider file (e.g., `mostro_service_provider.dart`), not by importing a separate provider file.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
lib/features/trades/widgets/mostro_message_detail_widget.dart (1)
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
lib/data/models/nostr_event.dart (3)
Learnt from: chebizarro
PR: MostroP2P/mobile#127
File: lib/data/models/cant_do.dart:10-27
Timestamp: 2025-07-08T05:40:47.506Z
Learning: In the CantDo model parsing in lib/data/models/cant_do.dart, the inconsistent key naming between 'cant_do' (top-level) and 'cant-do' (nested) is required by the protocol specification and should not be changed as it would break message parsing compatibility.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
lib/core/app.dart (1)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, Riverpod code generation is used with `@Riverpod` annotations. Providers like `eventStorageProvider` are generated in `.g.dart` files from annotated functions in the main provider files. These providers are accessible by importing the main provider file (e.g., `mostro_service_provider.dart`), not by importing a separate provider file.
lib/main.dart (1)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
lib/shared/widgets/bottom_nav_bar.dart (3)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, Riverpod code generation is used with `@Riverpod` annotations. Providers like `eventStorageProvider` are generated in `.g.dart` files from annotated functions in the main provider files. These providers are accessible by importing the main provider file (e.g., `mostro_service_provider.dart`), not by importing a separate provider file.
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
lib/features/order/models/order_state.dart (1)
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: lib/features/trades/widgets/mostro_message_detail_widget.dart:134-141
Timestamp: 2025-06-08T23:54:09.987Z
Learning: In the OrderState refactor, public keys should be accessed via `tradeState.peer?.publicKey` from the OrderState instance rather than through `session?.peer?.publicKey`, as the OrderState encapsulates peer information directly.
lib/features/home/screens/home_screen.dart (2)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, Riverpod code generation is used with `@Riverpod` annotations. Providers like `eventStorageProvider` are generated in `.g.dart` files from annotated functions in the main provider files. These providers are accessible by importing the main provider file (e.g., `mostro_service_provider.dart`), not by importing a separate provider file.
lib/features/trades/widgets/trades_list_item.dart (3)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/features/trades/models/trade_state.dart:1-15
Timestamp: 2025-05-08T16:06:33.665Z
Learning: In the context of the Mostro Mobile app, the `TradeState` class is specifically constructed using the `tradeStateProvider`. While some fields are nullable (`lastAction` and `orderPayload`), they are still marked as required parameters to ensure they are explicitly considered during state construction.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, Riverpod code generation is used with `@Riverpod` annotations. Providers like `eventStorageProvider` are generated in `.g.dart` files from annotated functions in the main provider files. These providers are accessible by importing the main provider file (e.g., `mostro_service_provider.dart`), not by importing a separate provider file.
lib/features/trades/screens/trade_detail_screen.dart (3)
Learnt from: chebizarro
PR: MostroP2P/mobile#74
File: lib/features/trades/models/trade_state.dart:1-15
Timestamp: 2025-05-08T16:06:33.665Z
Learning: In the context of the Mostro Mobile app, the `TradeState` class is specifically constructed using the `tradeStateProvider`. While some fields are nullable (`lastAction` and `orderPayload`), they are still marked as required parameters to ensure they are explicitly considered during state construction.
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
Learnt from: chebizarro
PR: MostroP2P/mobile#110
File: lib/features/trades/widgets/mostro_message_detail_widget.dart:134-141
Timestamp: 2025-06-08T23:54:09.987Z
Learning: In the OrderState refactor, public keys should be accessed via `tradeState.peer?.publicKey` from the OrderState instance rather than through `session?.peer?.publicKey`, as the OrderState encapsulates peer information directly.
🪛 YAMLlint (1.37.1)
.github/workflows/flutter.yml
[error] 20-20: trailing spaces
(trailing-spaces)
🪛 LanguageTool
ADDING_NEW_LANGUAGE.md
[grammar] ~14-~14: Using ‘plenty’ without ‘of’ is considered to be informal.
Context: ...tion for: - Order Creation Forms - Amount entry, payment methods, premium settings - **...
(PLENTY_OF_NOUNS)
[uncategorized] ~206-~206: The preposition “with” seems more likely in this position.
Context: ... When translating, maintain consistency for these core concepts: - Bitcoin/BTC...
(AI_EN_LECTOR_REPLACEMENT_PREPOSITION)
CLAUDE.md
[uncategorized] ~66-~66: Possible missing preposition found.
Context: ...isting feature-based folder structure - Keep UI code declarative and side-effect fre...
(AI_HYDRA_LEO_MISSING_TO)
[misspelling] ~66-~66: Did you mean “side effect” (=adverse effect, unintended consequence)? Open compounds are not hyphenated.
Context: ...tructure - Keep UI code declarative and side-effect free - Use S.of(context).yourKey for ...
(AFFECT_EFFECT)
🪛 markdownlint-cli2 (0.17.2)
ADDING_NEW_LANGUAGE.md
33-33: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
289-289: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
294-294: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
301-301: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
308-308: Trailing punctuation in heading
Punctuation: ':'
(MD026, no-trailing-punctuation)
309-309: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
337-337: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🪛 RuboCop (1.75.5)
lib/l10n/intl_en.arb
[warning] 280-280: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 286-286: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 287-287: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 288-288: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 289-289: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 306-306: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 388-388: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 404-404: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
lib/l10n/intl_es.arb
[warning] 280-280: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 286-286: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 287-287: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 288-288: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 289-289: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 306-306: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 388-388: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 404-404: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
lib/l10n/intl_it.arb
[warning] 280-280: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 286-286: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 287-287: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 288-288: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 289-289: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 306-306: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 388-388: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
[warning] 404-404: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
🔇 Additional comments (42)
pubspec.yaml (1)
75-75: share_plus 9.0.0 — no known vulnerabilities; latest is 11.0.0 requiring Flutter SDK ≥3.22.0
- share_plus 9.0.0 (released Apr 2024) has no publicly reported CVEs or security issues.
- The newest stable is 11.0.0 (Apr 2025), which bundles further bug fixes and improvements.
- Note: 11.0.0 mandates Flutter SDK ≥3.22.0 (your current constraint ^3.5.3 falls below this).
If you’re satisfied with your existing SDK, keeping 9.0.0 poses no security risk. Otherwise, upgrade Flutter to ≥3.22.0 before bumping to share_plus 11.0.0.
lib/shared/widgets/mostro_app_bar.dart (1)
21-21: LGTM! Modern Flutter API usage.The change from
withOpacity()towithValues(alpha:)follows modern Flutter API practices and is functionally equivalent while being more explicit about the alpha channel modification.lib/features/rate/rate_counterpart_screen.dart (2)
34-34: LGTM! Good widget lifecycle management.The
mountedcheck before navigation prevents potential errors when the widget is disposed before the async operation completes. This is a Flutter best practice for widget safety.
44-45: LGTM! Internationalization support added.The replacement of hardcoded strings with localized strings using
S.of(context)!properly supports internationalization, which aligns with the PR objectives of enhancing the app's localization capabilities.Also applies to: 88-88
lib/features/order/screens/add_lightning_invoice_screen.dart (1)
58-58: Excellent addition of context.mounted safety checks!These mounted checks properly protect against attempting UI operations (navigation and snackbar display) after asynchronous operations when the widget may have been disposed. This prevents potential runtime errors and follows Flutter best practices for widget lifecycle management.
Also applies to: 60-67, 76-76, 78-85
lib/shared/widgets/mostro_reactive_button.dart (1)
75-75: Good cleanup of unused variable assignment.Removing the unused
orderStatevariable assignment while keeping theref.watchcall maintains the reactive behavior without unnecessary variable storage. This is a clean optimization.lib/main.dart (1)
17-17: Well-implemented timeago localization setup.The timeago localization initialization is properly placed in the app startup sequence and correctly configures Spanish and Italian locales. The implementation follows timeago package conventions and includes helpful comments explaining the setup.
Also applies to: 38-39, 60-69
lib/background/background_service.dart (1)
15-15: Background Service Factory: Desktop constructor updatedThe removal of the
settingsparameter from theDesktopBackgroundService()call in
lib/background/background_service.dart:15is intentional and correct.
The desktop service now receives and applies settings dynamically via its
updateSettings(Settings settings)method rather than at construction.Key points:
DesktopBackgroundServicehas no explicit constructor parameters.- Runtime settings changes are handled in
desktop_background_service.dartvia:@override void updateSettings(Settings settings) { … }No further changes needed.
lib/data/models/nostr_event.dart (2)
40-40: Good addition of localized time formatting API.The new
timeAgoWithLocalemethod provides a clean way to get localized time strings while maintaining backward compatibility with the existingexpirationgetter.
63-77: Verify Spanish as default timeago localeThe
_timeAgohelper hardcodes'es'when no locale is passed, which could conflict with the app’s resolved locale (e.g. Italian). Please confirm whether Spanish should always be the fallback or if it should instead use the app’s current locale.• lib/data/models/nostr_event.dart (lines 63–77):
Current fallback →
dart final effectiveLocale = locale ?? 'es';
• lib/core/app.dart:
- App-level
localeResolutionCallbackonly forces Spanish for device-language “es” and otherwise returnsnull(letting Flutter pick a supported locale).- Timeago locales registered: Spanish and Italian.
If Spanish isn’t intended as a universal fallback, consider replacing the hardcoded ‘es’ with the app’s resolved locale (or system default).
lib/features/order/models/order_state.dart (1)
224-240: Consistent addition of sendDm action for seller role.The
Action.sendDmhas been systematically added to appropriate active trading states, enabling direct messaging functionality when orders are in progress. This enhancement aligns with improving user communication during trades.lib/shared/widgets/custom_drawer_overlay.dart (4)
7-7: Good addition of localization support.Adding the generated localization import enables the drawer menu to display translated strings, supporting the app's internationalization effort.
31-31: Modern Flutter color API usage.The changes from
withOpacity()towithValues(alpha:)align with newer Flutter API patterns for color manipulation, maintaining the same visual result while using the recommended approach.Also applies to: 63-63
102-124: Excellent internationalization implementation.The replacement of hardcoded English strings with localized strings using
S.of(context)!properly internationalizes the drawer menu items. The implementation follows the correct pattern for accessing generated localization strings.
36-43: PopScope migration verified – all clear
- No remaining
WillPopScopeusages found inlib/PopScopeis only used inlib/shared/widgets/custom_drawer_overlay.dart- The
canPop: !isDrawerOpencheck andonPopInvokedWithResultcallback correctly intercept back presses to close the drawer when it’s open, and only allow navigation pop when it’s closedNo changes required.
lib/shared/widgets/bottom_nav_bar.dart (1)
6-6: LGTM! Solid internationalization implementation.The localization changes are well-implemented:
- Proper import of generated localization class
- Consistent replacement of hardcoded strings with localized versions
- Semantic labels are appropriately localized for accessibility
- Color opacity method updated to modern
withValuesapproachAlso applies to: 31-31, 42-42, 48-48, 55-55, 77-77
lib/features/walkthrough/screens/walkthrough_screen.dart (1)
4-4: Excellent refactoring for internationalization support.The changes properly enable localization:
- Moving static
PageViewModellist to a context-aware method allows access to localized strings- Const constructor optimization
- All user-facing strings properly localized
- Clean separation of concerns between static structure and dynamic content
Also applies to: 7-7, 9-45, 56-56, 60-62
lib/shared/widgets/pay_lightning_invoice_widget.dart (1)
7-8: Great UX enhancement with proper internationalization.Excellent improvements:
- Enhanced user experience with separate copy and share buttons
- Proper error handling for share functionality with mounted check
- Comprehensive localization of all user-facing strings
- Clean integration of
share_pluspackage- Appropriate feedback messages for both success and error scenarios
Also applies to: 34-38, 49-55, 59-112, 123-123, 137-137, 150-150
lib/core/app.dart (1)
1-1: Well-implemented custom locale resolution logic.The locale handling is robust:
- Proper system locale detection via
PlatformDispatcher- Spanish language prioritization with variant support (es_AR, es_ES, etc.)
- Sensible fallback hierarchy to English
- Clean integration with Flutter's localization system
Also applies to: 50-58, 66-83
lib/l10n/intl_it.arb (1)
58-404: Comprehensive Italian localization coverage.Excellent work on providing extensive Italian translations covering:
- Authentication flows and onboarding
- Order creation and management
- Trade statuses and actions
- Chat interface
- Error messages and validation
- Settings and account management
The localization strings include proper placeholders and pluralization support where needed.
lib/l10n/intl_es.arb (1)
1-405: Excellent Spanish localization coverage.The Spanish translations are comprehensive and appear to maintain consistency with Bitcoin/crypto terminology. The cultural adaptations are appropriate (e.g., "días de 👴" for "days old" adds a nice touch).
lib/features/trades/widgets/trades_list_item.dart (4)
14-14: Good localization integration.Properly imports the generated localization class for internationalization support.
58-58: Excellent localization implementation.Properly replaces hardcoded strings with localized equivalents using
S.of(context)!. The dynamic text selection for buying vs selling Bitcoin enhances user experience.Also applies to: 130-130, 160-160
152-152: Correct method signature updates for localization.Properly updates method signatures to accept
BuildContextparameter, enabling access to localization resources. This follows Flutter internationalization best practices.Also applies to: 170-170
177-177: Modernized opacity method and improved status handling.The change from
.withOpacity(0.3)to.withValues(alpha: 0.3)follows modern Flutter recommendations. The explicit handling ofwaitingPaymentandwaitingBuyerInvoicestatuses with dedicated labels improves user clarity instead of generic "Pending" labels.Also applies to: 182-189, 193-196
lib/features/home/screens/home_screen.dart (4)
13-13: Proper localization import.Correctly imports the generated localization class for internationalization support.
69-69: Good localization of empty state messages.Replaces hardcoded empty state text with localized strings, improving user experience for international users.
Also applies to: 76-76
118-118: Correct method signature updates for localization.Properly updates method signatures to accept
BuildContextparameter and removes inappropriateconstmodifiers where localized strings are used. This enables proper access to localization resources.Also applies to: 134-135, 142-143, 154-156
136-136: Excellent localization of UI labels.Properly replaces hardcoded button labels and UI text with localized equivalents, including parameterized strings for the offers count. This ensures consistent internationalization across the home screen.
Also applies to: 144-144, 237-237, 252-252
ADDING_NEW_LANGUAGE.md (2)
1-355: Excellent localization documentation.This comprehensive guide provides clear, step-by-step instructions for adding new languages to the app. The structure is logical, examples are helpful, and the troubleshooting section addresses common issues. The AI assistant instructions are particularly valuable for maintaining consistency.
285-317: Valuable AI assistant integration guidance.The AI assistant instructions provide excellent guidance for automated localization tasks. This will help ensure consistency when AI tools are used to add new languages or update existing translations.
CLAUDE.md (1)
1-203: Excellent comprehensive documentation for AI assistance.This documentation file provides thorough guidance covering architecture, development workflows, internationalization, and project context. The structured approach with clear sections makes it an invaluable resource for maintaining consistency and quality across the codebase.
lib/features/trades/screens/trade_detail_screen.dart (10)
2-2: Import added for safer collection operations.The
collection/collection.dartimport enables the use offirstWhereOrNullfor safer session access, which is a good improvement over potentially throwing operations.
20-20: Localization support added correctly.The import of the generated localization file enables proper internationalization throughout the screen.
42-42: App bar title properly localized.The hardcoded string has been correctly replaced with a localized version.
86-89: Method signature and session access improved.The changes include:
- Adding
BuildContextparameter to enable localization access- Using
firstWhereOrNullfor safer session retrieval- Updating the provider reference
These are solid improvements that enhance both functionality and safety.
116-118: Timestamp handling fixed for consistency.The conversion from seconds to milliseconds (
createdAt! * 1000) ensures consistent timestamp handling throughout the application, which is important for proper date/time display.
130-134: Dynamic role-based messaging properly localized.The conditional text display based on seller/buyer role is well-implemented with proper localization. The parameterized strings allow for flexible message composition while maintaining translation support.
192-192: Method signature updated for localization consistency.Adding the
BuildContextparameter enables proper localization access within the countdown time widget.
238-280: Enhanced cancel dialog with proper confirmation.The implementation provides:
- Context-aware cancel messages based on trade status
- Proper confirmation dialog with localized labels
- Clear action buttons with appropriate styling
This improves user experience by providing clear feedback and preventing accidental cancellations.
488-488: Navigation change aligns with PR objectives.The change from
context.pop()tocontext.go('/order_book')ensures users are directed to the order book when closing the trade detail screen. This supports the PR objective of making user-created orders visible in the order book.
58-62: No action required: timestamp conversion is consistent
We’ve verified thatexpiresAt(and other timestamp fields) are stored in seconds inlib/data/models/order.dartand consistently converted to milliseconds (via* 1000) whereverDateTime.fromMillisecondsSinceEpochis used—e.g.:
- lib/features/trades/screens/trade_detail_screen.dart
- lib/shared/utils/nostr_utils.dart
- lib/data/repositories/event_storage.dart
All conversions align with the rest of the codebase.
| test('Taking a Buy Order - seller sends take-buy and receives pay-invoice confirmation', () async { | ||
| // Confirmation JSON for "Taking a buy order": | ||
| // ignore: unused_local_variable |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove unused variables instead of suppressing warnings.
The confirmation JSON objects are declared but never used in the tests. Consider either:
- Removing these unused variables entirely
- Actually using them in the test logic if they serve a purpose
Suppressing warnings for genuinely unused code is not ideal as it can hide real issues.
- // ignore: unused_local_variable
- final confirmationJsonTakeBuy = {
- // ... JSON content
- };Apply similar changes to remove all unused confirmation JSON objects across the test cases.
Also applies to: 148-148, 210-210, 274-274
🤖 Prompt for AI Agents
In test/notifiers/take_order_notifier_test.dart at lines 79, 148, 210, and 274,
there are unused confirmation JSON variables declared and ignored with comments.
Remove these unused variables entirely from the test cases since they are not
used in the test logic, instead of suppressing the warnings. This cleanup will
prevent hiding potential issues and keep the codebase clean.
| class DesktopBackgroundService implements BackgroundService { | ||
| final _subscriptions = <String, Map<String, dynamic>>{}; | ||
| bool _isRunning = false; | ||
| final bool _isRunning = false; |
There was a problem hiding this comment.
Critical: Immutable _isRunning field breaks service functionality.
Setting _isRunning as final bool _isRunning = false; means the service will never be considered "running", causing all service methods (subscribe, setForegroundStatus, unsubscribe, etc.) to return early without performing their intended operations.
Apply this fix to make the field properly mutable and manage the running state:
- final bool _isRunning = false;
+ bool _isRunning = false;You'll also need to properly set _isRunning = true when the service starts (likely in the init() method or when the isolate confirms it's running).
🤖 Prompt for AI Agents
In lib/background/desktop_background_service.dart at line 15, the _isRunning
field is declared as final, making it immutable and preventing the service from
updating its running state. Change the declaration to a non-final mutable
boolean field. Then, ensure _isRunning is set to true when the service starts,
such as in the init() method or when the isolate confirms it is running, so that
service methods can operate correctly.
| Settings _settings; | ||
|
|
||
| DesktopBackgroundService(this._settings); | ||
| DesktopBackgroundService(); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Constructor change aligns with settings field removal.
The parameterless constructor is consistent with the removal of the _settings field. However, verify that the desktop service doesn't need settings for proper operation, especially for isolate communication.
🏁 Script executed:
#!/bin/bash
# Description: Check if settings are needed in the isolate or service logic
# Search for settings usage in isolate entry point
rg -A 10 -B 5 "isolateEntry" lib/background/desktop_background_service.dart
# Check if settings are used in the service initialization
rg -A 10 -B 5 "Settings" lib/background/desktop_background_service.dartLength of output: 1416
🏁 Script executed:
#!/bin/bash
# Inspect the DesktopBackgroundService class definition
rg -n -C5 "class DesktopBackgroundService" lib/background/desktop_background_service.dartLength of output: 581
#!/bin/bash
# Search for instantiations of DesktopBackgroundService
rg -n "DesktopBackgroundService"
# Search for where BackgroundService is constructed for desktop
rg -n "BackgroundService" -C3 .Ensure desktop isolate receives initial and subsequent settings
The parameterless constructor correctly removes the _settings field, but the service never forwards settings to the isolate at startup or on change:
• In lib/background/desktop_background_service.dart:15, change
final bool _isRunning = false;to a mutable bool _isRunning = false; and set it to true once the isolate has started so that updateSettings() actually sends messages.
• In DesktopBackgroundService.init() (same file), after spawning the isolate and initializing the messenger, send the current settings (e.g. settings.toJson()) to the isolate’s receive port so it starts with the correct configuration.
🤖 Prompt for AI Agents
In lib/background/desktop_background_service.dart at line 18, change the
_isRunning field from a final bool to a mutable bool and set it to true once the
isolate has started. Then, in the DesktopBackgroundService.init() method, after
spawning the isolate and initializing the messenger, send the current settings
(converted to JSON) to the isolate's receive port to ensure it receives the
initial configuration and subsequent updates.
| Action.sendDm, | ||
| ], | ||
| Action.holdInvoicePaymentSettled: [ | ||
| Action.fiatSent, | ||
| Action.cancel, | ||
| Action.dispute, | ||
| Action.sendDm, | ||
| ], | ||
| Action.buyerTookOrder: [ | ||
| Action.cancel, | ||
| Action.dispute, | ||
| Action.sendDm, | ||
| ], | ||
| Action.cooperativeCancelInitiatedByPeer: [ | ||
| Action.cancel, | ||
| Action.dispute, | ||
| Action.sendDm, | ||
| ], | ||
| }, | ||
| Status.fiatSent: { | ||
| Action.fiatSentOk: [ | ||
| Action.cancel, | ||
| Action.dispute, | ||
| Action.sendDm, | ||
| ], |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Consistent addition of sendDm action for buyer role.
The Action.sendDm implementation for buyers matches the seller implementation, maintaining consistency across roles. The addition to both active and fiat-sent states provides appropriate communication opportunities.
🏁 Script executed:
#!/bin/bash
# Description: Verify sendDm action is properly handled in UI components
# Check if sendDm action is handled in order/trade screens
rg -A 5 -B 5 "sendDm\|Action\.sendDm" lib/features/order/ lib/features/trades/
# Check if there's a UI component for handling direct messages
fd -e dart -x rg -l "sendDm\|direct.*message\|dm" {} \; lib/features/Length of output: 513
Implement UI support for the new sendDm action
I ran searches in lib/features/order and lib/features/trades for Action.sendDm (and related DM keywords) and found no handlers or UI components wired up. To ensure buyers can actually send a DM when this action appears, please:
- Add a “Send DM” button or menu item in your order-actions widget (e.g.
lib/features/order/presentation/widgets/order_actions.dart) - Wire its
onPressed(or equivalent) to dispatchAction.sendDmand open the DM composer - Update any trade-detail screens under
lib/features/trades/…to include the send-DM option alongside other actions
🤖 Prompt for AI Agents
In lib/features/order/models/order_state.dart around lines 298 to 322, the new
Action.sendDm is defined but lacks UI support. To fix this, add a "Send DM"
button or menu item in the order-actions widget, such as in
lib/features/order/presentation/widgets/order_actions.dart, and wire its
onPressed handler to dispatch Action.sendDm and open the DM composer. Also,
update trade-detail screens under lib/features/trades/ to include the send-DM
option alongside other actions, ensuring users can trigger the sendDm action
from the UI.
|
|
||
| "@_comment_price_type_section": "Stringhe Sezione Tipo di Prezzo", | ||
| "priceType": "Tipo di prezzo", | ||
| "marketPrice": "Prezzo di mercato", |
There was a problem hiding this comment.
Critical Issue: Duplicate localization keys must be resolved.
The static analysis correctly identified duplicate keys in the Italian ARB file:
"marketPrice"(lines 280, 286)"orderDetails"(line 286)"selling"(line 287)"buying"(line 288)"atMarketPrice"(line 289)"noPaymentMethod"(line 306)"rate"(line 388)"done"(line 404)
These duplicates will break the localization system and must be removed or renamed to unique keys.
# Remove or rename the duplicate entries. For example, if the second occurrence should be different:
- "marketPrice": "Prezzo di mercato",
+ "marketPriceLabel": "Prezzo di mercato",Please review each duplicate and either remove redundant entries or create unique, descriptive keys for different contexts.
Also applies to: 286-289, 306-306, 388-388, 404-404
🧰 Tools
🪛 RuboCop (1.75.5)
[warning] 280-280: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
🤖 Prompt for AI Agents
In lib/l10n/intl_it.arb around lines 280 to 289, 306, 388, and 404, there are
duplicate localization keys such as "marketPrice", "orderDetails", "selling",
"buying", "atMarketPrice", "noPaymentMethod", "rate", and "done". To fix this,
identify each duplicate key and either remove the redundant entries or rename
them with unique, descriptive keys that reflect their specific context to ensure
all keys are unique and prevent conflicts in the localization system.
|
|
||
| "@_comment_price_type_section": "Cadenas de Sección de Tipo de Precio", | ||
| "priceType": "Tipo de precio", | ||
| "marketPrice": "Precio de mercado", |
There was a problem hiding this comment.
Fix duplicate keys (inherited from English file).
This Spanish localization file has the same duplicate key issues as the English file:
- Line 280:
"marketPrice" - Lines 286-289:
"orderDetails","selling","buying","atMarketPrice" - Line 306:
"noPaymentMethod" - Line 388:
"rate" - Line 404:
"done"
Please resolve the duplicate keys to ensure proper localization functionality. The Spanish translations themselves appear to be of good quality.
Also applies to: 286-289, 306-306, 388-388, 404-404
🧰 Tools
🪛 RuboCop (1.75.5)
[warning] 280-280: Duplicated key in hash literal.
(Lint/DuplicateHashKey)
🤖 Prompt for AI Agents
In lib/l10n/intl_es.arb at lines 280, 286-289, 306, 388, and 404, there are
duplicate keys such as "marketPrice", "orderDetails", "selling", "buying",
"atMarketPrice", "noPaymentMethod", "rate", and "done". To fix this, identify
and remove or rename the duplicate keys so each key appears only once in the
file, ensuring unique keys for proper localization functionality.
|
Esta primera orden que aparece la creé yo, pero no me sale la etiqueta por mí. Si la orden es tomada, sí me avisa que alguien la tomó y la puedo completar. |
|
Hi @chebizarro what is the status of this PR? |
…import in trade detail screen
|
Hi @chebizarro
|
|
ping @chebizarro |
This PR ensures that orders created by the user are visible in the main order book, not just under "My Trades."
Additionally, the order label now displays a "YOU ARE" indicator next to user-created orders trade type, making it easy to distinguish which orders belong to the current user at a glance. This improves clarity and helps users quickly identify their own orders in the list.
Summary by CodeRabbit
New Features
Localization
Chores