WIP: Reference Only - DO NOT MERGE #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "tac"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
NOTES
Tac Prefixed Controllers and routes are no longer used
Place::createFromMixedto always have spatial point 500547d7b3**Versioning Strategy:** - Cache keys now include version number: live:{company}:{endpoint}:v{version}:{params} - Version increments on model changes to invalidate all related caches - Works with ANY cache driver (file, database, Redis, Memcached) - Dual strategy: version increment + tag flush (if tags supported) **Benefits:** - No race conditions - old keys become invalid immediately - Cache driver agnostic - doesn't require Redis/Memcached tags - Automatic cleanup - old versioned keys expire with TTL - Backward compatible - existing observers work without changes **How It Works:** 1. Order updated → OrderObserver calls invalidate('orders') 2. Version increments: orders v1 → v2 3. Old cache keys (v1) are now orphaned and ignored 4. New requests use v2 keys and rebuild cache 5. Old v1 keys expire naturally after 30s TTL **Example:** - Before: live:company123:orders:abc123 - After: live:company123:orders:v5:abc123 - On update: v5 → v6 (all v5 keys instantly invalid)with_tracker_dataparam on active orders 16b0f9c5d3OrderController Changes: - Add Cache facade import - Implement 30-second caching for trackerInfo endpoint - Cache key format: order:{uuid}:tracker OrderObserver Changes: - Add Cache facade import - Update invalidateCache to accept optional Order parameter - Invalidate order-specific tracker cache on created/updated/deleted events - Ensures fresh tracker data after order changes Performance Benefits: - Reduces OSRM API calls for repeated tracker requests - 30-second cache prevents excessive API usage - Automatic invalidation ensures data freshness - Significant performance improvement for lazy-loaded tracker dataRemove generateFixedRateFees() calls from controllers before save. **The Problem:** - Service creates local unsaved records when user changes max_distance - Controller called generateFixedRateFees() again before save (defensive) - Backend returns saved records with IDs - Ember Data adds saved records to relationship - Local unsaved records still in relationship - Result: Duplicates (local + saved) **The Solution:** - Remove generateFixedRateFees() calls from save tasks - Fees are already created by form interactions: 1. User selects Fixed Rate → selectRateCalculationMethod() creates fees 2. User changes max_distance → onMaxDistanceChange() creates/updates fees - No need to call again before save - Ember Data updates local records with IDs from backend response - No duplicates ✅ **Files Changed:** - addon/controllers/operations/service-rates/index/new.js - addon/controllers/operations/service-rates/index/edit.js **Result:** - Clean save flow - No duplicates after save - All fees display correctly (0-1 km, 1-2 km, etc.)**The Persistent Problem:** Even after removing the defensive generateFixedRateFees() call, duplicates still appeared because Ember Data doesn't automatically merge/remove local unsaved records when the backend returns saved versions. **The Flow:** 1. User creates fees → local unsaved records created 2. User saves → backend returns saved records with IDs 3. Ember Data adds saved records to relationship 4. Local unsaved records remain in relationship 5. Result: Duplicates (local unsaved + backend saved) **The Solution:** Add cleanupDuplicateRateFees() method that runs AFTER save: - Identifies unsaved records (isNew = true) - Identifies saved records (isNew = false) - Removes unsaved records that have same distance as saved records - Unloads them from Ember Data **Implementation:** - Service: cleanupDuplicateRateFees() method - Controllers: Call cleanup after successful save - Only runs for Fixed Rate service rates **Result:** - No duplicates after save ✅ - Clean rate_fees relationship - rateFees computed property returns correct data**Issue:** Fee values were being sent as formatted strings ("₮2,000") instead of cents strings ("200000"), causing database errors. **Root Cause:** MoneyInput was using one-way binding @value={{rateFee.fee}} without @onChange handler. For nested relationship properties (rateFee.fee), the two-way binding wasn't working automatically. **Solution:** Added explicit @onChange={{fn (mut rateFee.fee)}} to MoneyInput. **How It Works:** - User types: 2000 - MoneyInput displays: ₮2,000 (formatted) - MoneyInput converts to cents: "200000" - @onChange updates rateFee.fee with cents string - Backend receives: "200000" (cents as string) ✅ **Why fee is string:** - Backend stores cents as integer - Model stores cents as string ("200000") - MoneyInput converts cents string ↔ formatted display - Server converts cents to/from currency amount **Result:** - Fee values save correctly ✅ - No database errors ✅ - Proper cents storage ✅The real issue was backend Money cast, not frontend binding. Backend ServiceRateFee model was not using Money cast properly, which has been fixed on the backend side. The frontend MoneyInput was working correctly all along. Reverted: - Removed @onChange={{fn (mut rateFee.fee)}} from MoneyInput - MoneyInput's default two-way binding works fine The issue is now resolved with the backend fix.**Issue:** Previous commit added map(fn($row) => Model::onRowInsert($row)) before bulkInsert(), but this is redundant because the Insertable trait already calls onRowInsert(). **Insertable Trait (core-api):** The bulkInsert() method from Insertable trait already does: ```php if (method_exists($model, 'onRowInsert')) { $rows[$i] = static::onRowInsert($rows[$i]); } ``` **What Was Redundant:** - map() calling onRowInsert() before bulkInsert() - This caused onRowInsert() to be called TWICE: 1. In setServiceRateFees() via map() 2. In bulkInsert() via Insertable trait **What's Still Needed:** - onRowInsert() call before update() queries ✅ - Update operations bypass the Insertable trait - They need explicit transformation **Changes:** 1. setServiceRateFees(): - Kept: onRowInsert() before update() ✅ - Removed: map() before bulkInsert() ❌ (redundant) 2. setServiceRateParcelFees(): - Kept: onRowInsert() before update() ✅ - Removed: map() before bulkInsert() ❌ (redundant) **Result:** - ✅ Update operations: Apply onRowInsert() (necessary) - ✅ Bulk insert operations: Let Insertable trait handle it (automatic) - ✅ No redundant transformations - ✅ Cleaner code Thanks for catching this!window.Fleetbase, improve several order related functions 8f8e9a11eaView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.