Advanced Product Filtering & Bulk Operations

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €15–25/month

Generated from docs/plan/paid/advanced-product-filtering-bulk-operations/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid admin productivity feature for merchants with >500 SKUs. Enables merchants to find products using complex filters (e.g., ‘brand=Nike AND material=plastic AND inventory<10’) and bulk-perform actions (edit attribute, change category, update price, archive) without touching spreadsheets. Pays for itself in 5 operations for mid-market shops.

The problem

I have 2,000 products with 40 attributes. Finding ‘discontinued products in category Clearance with inventory < 5’ takes 10 minutes with advanced Excel tricks. Bulk-updating 100 products to new category or price tier requires manual editing. I need a product finder and bulk editor built into admin.

What it does

• Advanced filter builder: chainable filters (brand=Nike AND material=plastic AND price>100 OR inventory<10)
• Saved filters: save complex filter as ‘Low Stock Clearance Items’, apply again later
• Bulk actions: edit attribute (set brand=Nike for all), change category, update price (add €10, multiply by 1.2), archive/delete, assign tags, update status (draft→published)
• Bulk preview: show first 20 products matching filter before applying bulk action
• Undo bulk action: track bulk operations, allow reverting last bulk change (within 24 hours)
• Bulk export: export filtered products to CSV (with custom column selection) for external use (spreadsheet, printer)
• Bulk import: re-import CSV changes (prices, attributes) and merge back into catalog
• Scheduled bulk operations: ‘every Monday, archive products in Clearance with inventory=0’ (automation)
• Audit trail: log all bulk operations (who, what, when, how many products affected, undo available)
• Performance: handle 10,000+ products without slowdown (async operations with progress tracking)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Automatic product categorization — that is ML classification, separate paid module.
• Bulk fulfillment operations — that is fulfillment module (create shipments, send labels).
• Bulk customer operations — this is products only; customers are separate.
• AI-powered bulk suggestions (‘here are 50 products you should archive’) — that is AI insights module.
• Integration with third-party tools (sync to Zapier, import from Airtable) — integrations are platform features, not product module.

Data model

New BULK_OPERATION_LOG table (operation_id, merchant_id, filter_json, action_type, action_params JSON, product_ids JSON, executed_at, undo_available_until, status (pending|completed|failed|undone)). New SAVED_FILTER table (filter_id, merchant_id, filter_name, filter_json, created_at). Migration required: none (new tables).

API

• POST /admin/products/search (execute filter query, return product count + first 20 products)
• POST /admin/filters/save (save filter with name)
• GET /admin/filters (list saved filters)
• DELETE /admin/filters/:id (delete saved filter)
• POST /admin/products/bulk-action (execute bulk action: edit, category, price, archive)
• POST /admin/products/bulk-action/:operationId/undo (undo last bulk operation)
• GET /admin/products/bulk-operations (list history of bulk operations)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Products page with advanced filter panel: filter builder (add conditions, chains with AND/OR). Filter preview shows product count + first 20 results in table. Save Filter button. Bulk Action dropdown (edit attribute, change category, update price, archive, delete, export). Bulk preview modal before executing. Bulk operation history shows past operations with undo buttons (enabled for <24h old ops).

The seam — why this is paid

Paid module owns filter UI, bulk operation execution, undo/audit, and async processing. Core provides product API and inventory data. Paid module wraps core API with high-level bulk operations. No seam distinction needed; entire feature is paid.

Pure admin productivity. Merchants with <500 SKUs don’t need this; high-volume shops save significant time. Justifies paid because time ROI is high.

Dependencies

• flexible-product-attributes (for attribute filtering)
• Product model (core, existing)
• Audit log (core, for tracking operations)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Filter created: ‘brand=Nike AND material=plastic AND inventory<10’; matches 47 products
• Filter saved as ‘Low Stock Nike Plastic’; can be reused next week
• Bulk action preview: ‘Update 47 products: set status=archived’ — first 20 shown for confirmation
• Bulk action executed: 47 products archived; operation logged with undo button available for 24 hours
• Undo clicked: 47 products unarchived; operation log shows ‘undone’ status
• Export bulk action: filtered products exported to CSV with columns [product_id, name, price, inventory, material, brand]
• Scheduled bulk operation: ‘every Monday at 2AM, archive products in Clearance with inventory=0’ — runs automatically
• Audit trail shows: ‘User admin@shop.com updated 47 products at 2024-01-15 14:30; changed status to archived; undo available until 2024-01-16 14:30’

Risks

If bulk action is not transactional, partial updates occur (30 of 47 products updated, then error). Mitigate: wrap bulk action in transaction, rollback on error. If undo is not implemented, merchant mistakes are permanent. Mitigate: store operation details and old values, allow reverting within time window (24h default). If async operation is not tracked, merchant doesn’t know when bulk edit completes. Mitigate: show progress bar or notification when operation starts/completes. If bulk filter is slow (>5s to match 2000 products), admin page is unresponsive. Mitigate: use indexed queries, move matching to async if needed.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.