Editing an order in the portal created a second order

Your admin opens an order to correct a quantity and clicks Edit. The page that appears is an empty order form. She fills it in again, presses save, and the system cheerfully creates a second order. Now there are two, and nobody can say which one is real.

That was the state of the order portal Aries Agro uses for its dealers and depots. There was no working way for an admin to change an order that had been placed. The owner then asked for edit to work at any status, not only while an order was pending, and that is where the risk sat: a naive edit would have zeroed the shipped quantities on 7,029 completed order lines while 3,183 dispatch records still said those goods had left the warehouse.

What was actually going on

There were three problems stacked on top of each other.

The Edit screen had been wired to a web address that carried the order number, but the screen never read it. It drew a blank Add form. Saving a blank Add form adds an order.

Second, changing an order replaces its product lines wholesale. For a pending order that does no harm. For a completed one, it would wipe out how much of each line had been confirmed and how much remained to ship, while the dispatch records stayed put.

Third, when we tested, we found the order-change request could crash the whole service. The code that handled it could fail outside the place that catches errors, and in that version of the framework such a failure kills the process. A request with no order number took the service down, and the old check of who was allowed to edit failed the same way. In effect, any admin who had ever tried to modify an order had crashed production.

What we changed

Edit now reads the order. The hard-coded rule about who may modify orders was replaced with a proper permission. That permission already existed and had been granted to admins, but nothing enforced it, and ordinary sales reps did not hold it. So the grant for reps had to ship in the same deployment, or every rep using the mobile app would have lost the ability to modify an order.

Two refusals stay on purpose: you cannot remove a product that has been dispatched, and you cannot cut a line below what has already shipped. Nothing in the system can reduce or delete a dispatch, so an edit must never contradict one. The crash was fixed, and the change went to production on 26 August.

We tested it with five permission checks and six end-to-end runs, including one that showed the dispatch progress surviving an edit of a completed order.

What it did not fix

Editing cannot undo a dispatch. If goods shipped by mistake, a corrected order will refuse to go below what left the warehouse, and somebody has to decide what to do about the shipment. We have no figure for how many duplicate orders the blank form had created before we fixed it.

The pattern, for anyone letting staff edit completed records

Ask what the edit overwrites. If changing a line also replaces information that other records depend on, such as what has shipped, then an edit can be wrong without anything looking wrong.

And check that a permission you believe protects something is actually checked. Here, the permission existed and protected nothing.

Where this ends up

Sazinga Field lets an admin correct an order without creating a second one, and refuses the edits that would contradict what has already shipped.