riyadhafraa
de8333e659
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
105 lines
3.1 KiB
Plaintext
105 lines
3.1 KiB
Plaintext
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 |