Transitioned from Plan to Build mode

Replit-Commit-Author: Agent
Replit-Commit-Session-Id: 77cfe984-2c65-4152-bb7a-0df28274fe66
Replit-Commit-Checkpoint-Type: full_checkpoint
Replit-Commit-Event-Id: bf12c694-72b5-40f8-bb03-65f73ca59aa2
Replit-Commit-Screenshot-Url: https://storage.googleapis.com/screenshot-production-us-central1/c3c252e4-c83d-40ca-9fff-99a3ea60701e/77cfe984-2c65-4152-bb7a-0df28274fe66/PwtbShH
Replit-Helium-Checkpoint-Created: true

attached_assets/Pasted-Implement-the-Service-Orders-workflow-with-receiver-per_1776795235281.txt

@@ -0,0 +1,105 @@
+Implement the Service Orders workflow with receiver permissions.
+
+Business logic:
+1. Admin must be able to create users and control who is allowed to receive service orders.
+2. Add a dedicated permission for receiving orders, such as:
+   - orders.receive
+3. Any user with this permission should see incoming new service orders in the orders system.
+4. When a client places an order:
+   - the order should appear for all users who have the order-receiving permission
+   - they should get a realtime notification / bell alert
+5. The first receiver who clicks "Confirm Receipt" becomes the assigned handler of the order.
+6. Once confirmed:
+   - set assigned_to to that receiver
+   - update order status from pending to received
+   - notify the client that the order has been received and is being prepared
+7. The client should see statuses like:
+   - pending
+   - received
+   - preparing
+   - completed
+   - cancelled
+
+Client-side requirements:
+- Before placing the order, the client can add notes/comments
+- Remove service description from the order form / order display if currently shown there
+- The service description should remain only in the catalog managed by admin
+- The client should see clear status updates:
+  - order received
+  - preparing
+
+Admin requirements:
+- Admin manages the catalog only
+- Admin manages users and permissions
+- Admin can decide which users are allowed to receive service orders
+
+Database / backend requirements:
+1. Add permission:
+   - orders.receive
+2. Add service_orders table if not already added, with at least:
+   - id
+   - user_id
+   - service_id
+   - notes
+   - status
+   - assigned_to
+   - created_at
+   - updated_at
+3. Status flow:
+   - pending
+   - received
+   - preparing
+   - completed
+   - cancelled
+
+API requirements:
+- POST /api/orders
+- GET /api/orders/my
+- GET /api/orders/incoming
+- PATCH /api/orders/:id/confirm-receipt
+- PATCH /api/orders/:id/status
+
+Rules:
+- normal client can create order and view own orders
+- only users with orders.receive permission can see incoming orders
+- only one receiver can confirm receipt successfully
+- once receipt is confirmed, notify the client
+- use realtime bell/notification if Socket.IO already exists
+
+Frontend requirements:
+1. Client:
+- services catalog
+- order modal/form
+- notes field
+- submit order
+- my orders page with status
+
+2. Receiver side:
+- incoming orders page/list
+- bell notification for new orders
+- button: Confirm Receipt
+- after receipt, ability to move status to:
+  - preparing
+  - completed
+  - cancelled
+
+3. Admin:
+- manage users
+- assign or remove orders.receive permission
+- manage services catalog only
+
+Important:
+- Keep Arabic and English support
+- Keep RTL support
+- Keep it simple and operational
+- Remove unnecessary description duplication from order screens
+
+After implementation, provide a precise report:
+1. files changed
+2. database changes
+3. permission changes
+4. API endpoints added
+5. how incoming orders are routed to permitted users
+6. how confirm receipt works
+7. what notifications are implemented
+8. what is still pending