Feature/order cancel

[Srinjoy-git]

Overview

This PR adds cancel functionality for pending orders in the admin orders workflow.

Changes Made

• Added a cancel button for orders with pending status
• Added cancellation handling logic for order management
• Improved workflow flexibility for restaurant staff
• Updated UI flow to support order cancellation before cooking starts

Why This Feature?

In real restaurant operations, customers may cancel orders before preparation begins due to:

• changed decisions
• duplicate orders
• waiter input mistakes
• payment-related issues

Previously, pending orders could only move forward in the workflow. This feature improves real-world order management handling.

Files Updated

• OrderCard.jsx
• OrdersGrid.jsx

RestroHub-recording.mov

[Copilot]

Pull request overview

Adds “cancel pending order” support to the admin orders UI workflow, allowing staff to stop an order before it progresses to cooking/billing.

Changes:

• Added a Cancel button for orders in pending status on the order card.
• Added a cancellation handler that updates the order status to cancelled (currently via mocked delay).
• Updated orders grid status handler to remove cancelled orders from the local list (similar to completed orders).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
RestroHub-FrontEnd/src/components/admin/orders/orderComponents/OrdersGrid.jsx	Treats cancelled as a terminal status (removes order from list) in the status update handler.
RestroHub-FrontEnd/src/components/admin/orders/orderComponents/OrderCard.jsx	Adds cancel UI + handler for pending orders; updates layout to show action + cancel buttons side-by-side.

Comments suppressed due to low confidence (1)

RestroHub-FrontEnd/src/components/admin/orders/orderComponents/OrdersGrid.jsx:115

• handleStatusUpdate derives the next orders array from the orders value captured in the render that created this callback. Because updates are triggered after async work in OrderCard, two rapid status changes can race and the later call can overwrite the earlier change (e.g., re-introducing an order that was previously filtered out). Use a functional state update (and keep parent sync in the same place) so each update is based on the latest state.

  const handleStatusUpdate = (orderId, newStatus) => {
    if (newStatus === 'complete' || newStatus === 'cancelled') {
      syncOrders(orders.filter((o) => o.id !== orderId));
    } else {
      syncOrders(orders.map((o) => (o.id === orderId ? { ...o, status: newStatus } : o)));
    }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Srinjoy-git]

Hi @rdodiya ,

I wanted to follow up on this PR. The feature has been open for some time, and I was wondering if it aligns with the project's requirements.

If any modifications, fixes, or improvements are needed, I'd be happy to work on them. I'd appreciate any feedback regarding the current status of the PR.

Thank you!

[rdodiya]

Hi @Srinjoy-git ,
Please review above point and resolve conflicts.

[Karanjot786]

Hey @Srinjoy-git! Saw your work on GSSoC 2026.

We are building TermUI, a TypeScript terminal UI framework with React-style hooks and JSX, rendered entirely in the terminal.

We have 67 unassigned GSSoC issues open. 19 are marked good first issue. Your JavaScript background transfers directly.

• Open issues (GSSoC 2026)
• TermUI on GSSoC

Karanjot, TermUI maintainer