I'll implement a shop disable/enable feature that will:
Add a UI toggle in the frontend to enable/disable shops
Update the database to track the enabled/disabled state
Modify the background sync logic to skip disabled shops while still allowing manual sync
Ensure the store_sync_config table properly reflects the enabled state
I'll begin by examining the current implementation and then make the necessary changes.
@fszontagh I'm starting work on this issue now!
I'll implement a shop disable/enable feature that will:
1. Add a UI toggle in the frontend to enable/disable shops
2. Update the database to track the enabled/disabled state
3. Modify the background sync logic to skip disabled shops while still allowing manual sync
4. Ensure the `store_sync_config` table properly reflects the enabled state
I'll begin by examining the current implementation and then make the necessary changes.
The implementation leverages the existing store_sync_config table structure, which already had an enabled field. The WooCommerce scheduled sync was already checking this field, and I've now made the ShopRenter scheduled sync consistent with the same pattern.
@fszontagh The feature is ready for testing! Let me know if you'd like any adjustments to the UI/UX or behavior.
## ✅ Feature Implementation Complete
I've successfully implemented the shop disable/enable feature as requested. Here's what was done:
### 🎨 Frontend Changes
**Updated `IntegrationsContent.tsx`:**
- Added a new "Background Sync" column to the stores table
- Implemented a toggle Switch component for each store to enable/disable background sync
- Added `handleToggleStoreEnabled` function to manage the toggle state
- Modified `fetchStores` to include `store_sync_config` data via query parameter
- Toggle is automatically disabled during active sync operations to prevent conflicts
- Users receive clear toast notifications when toggling:
- **Enabled**: "Background sync will resume"
- **Disabled**: "Background sync is paused (manual sync still available)"
### 🔧 Backend Changes
**Updated `supabase/functions/api/index.ts`:**
- Added new `PUT /api/stores/:id/enable` endpoint to handle enable/disable requests
- Modified `GET /api/stores` to support `include_sync_config=true` query parameter
- Endpoint validates store ownership before allowing updates
- Automatically creates `store_sync_config` if it doesn't exist
- Updates existing config with proper timestamp tracking
**Updated `supabase/functions/shoprenter-scheduled-sync/index.ts`:**
- Modified to query stores with their `store_sync_config` data
- Added filtering logic to skip disabled stores
- Checks both `enabled` status and `next_sync_at` timing
- Updates `store_sync_config` timestamps after successful sync
- Auto-creates config for stores that don't have one yet
### ✨ Key Features
1. **Background Sync Control**: Users can enable/disable background sync per shop
2. **Manual Sync Always Available**: Even when disabled, manual sync button still works
3. **Smart Filtering**: Scheduled sync functions automatically skip disabled shops
4. **Safe Operations**: Toggle is disabled during active syncs to prevent race conditions
5. **Consistent Implementation**: Both WooCommerce and ShopRenter scheduled sync now use the same pattern
### 📋 What Happens When Disabled
- ✅ Scheduled background sync **skips** the shop
- ✅ Manual sync button **still works**
- ✅ Shop remains connected and active
- ✅ All data and settings are preserved
- ✅ Can be re-enabled anytime with a single click
### 🚀 Deployment
All changes have been:
- ✅ Committed to the repository (commit 3fb1f67)
- ✅ Pushed to origin/main
- ✅ Edge Functions deployed to Supabase:
- `api` (79.7kB)
- `shoprenter-scheduled-sync` (85.37kB)
### 🔍 Testing Notes
The implementation leverages the existing `store_sync_config` table structure, which already had an `enabled` field. The WooCommerce scheduled sync was already checking this field, and I've now made the ShopRenter scheduled sync consistent with the same pattern.
@fszontagh The feature is ready for testing! Let me know if you'd like any adjustments to the UI/UX or behavior.
Allow to the users to disable / enable shops. When shop is disabled, disable the background sync (but allow manual sync)
@fszontagh I'm starting work on this issue now!
I'll implement a shop disable/enable feature that will:
store_sync_configtable properly reflects the enabled stateI'll begin by examining the current implementation and then make the necessary changes.
✅ Feature Implementation Complete
I've successfully implemented the shop disable/enable feature as requested. Here's what was done:
🎨 Frontend Changes
Updated
IntegrationsContent.tsx:handleToggleStoreEnabledfunction to manage the toggle statefetchStoresto includestore_sync_configdata via query parameter🔧 Backend Changes
Updated
supabase/functions/api/index.ts:PUT /api/stores/:id/enableendpoint to handle enable/disable requestsGET /api/storesto supportinclude_sync_config=truequery parameterstore_sync_configif it doesn't existUpdated
supabase/functions/shoprenter-scheduled-sync/index.ts:store_sync_configdataenabledstatus andnext_sync_attimingstore_sync_configtimestamps after successful sync✨ Key Features
📋 What Happens When Disabled
🚀 Deployment
All changes have been:
3fb1f67)api(79.7kB)shoprenter-scheduled-sync(85.37kB)🔍 Testing Notes
The implementation leverages the existing
store_sync_configtable structure, which already had anenabledfield. The WooCommerce scheduled sync was already checking this field, and I've now made the ShopRenter scheduled sync consistent with the same pattern.@fszontagh The feature is ready for testing! Let me know if you'd like any adjustments to the UI/UX or behavior.
📊 Implementation Summary
Architecture Flow
State Flow
Files Modified
shopcall.ai-main/src/components/IntegrationsContent.tsx(+85 lines)supabase/functions/api/index.ts(+70 lines)supabase/functions/shoprenter-scheduled-sync/index.ts(+71 lines)