Draft Order Management

Resource Overview

The app panel manages purchasing activity through the Draft Orders resource.

This is the implemented order-management surface in the current build.

Current pages

  • list page
  • view page

There is no separate create-order screen in the Filament resource. Orders are expected to come from Shopify draft-order data.

Order List

The list currently shows:

  • Order Name
  • Status
  • Order By
  • Location
  • Drafted At
  • Total Amount
  • Budget Exceeded
  • Yearly Budget Exceeded
  • Monthly Budget Exceeded

Current filter

  • Status

Access scope

  • CompanyAdmin sees company orders for the current tenant
  • other users are filtered to orders for their assigned locations

Order Statuses

The order status enum currently defines:

  • draft
  • pending_approval
  • needs_rework
  • approved
  • processing
  • completed
  • cancelled
  • failed

These statuses are also used for dashboard widgets and badge colors.

Order Detail Actions

The order detail page can show these header actions when policy rules allow them:

Submit for Approval

  • intended for the requester-to-approval handoff
  • currently gated by a very narrow policy check

Send to Rework

  • moves the order to needs_rework
  • notifies the order owner

Confirm Order

  • sends the Shopify draft order for completion
  • changes status to processing
  • then to completed or failed

Action visibility is role- and state-dependent. If an action is not visible, it is not available for the current user in the current order context.

Order Lines

Each order includes an Order Lines relation manager.

Current capabilities

  • view line items
  • edit quantity
  • delete a line
  • add a new line by searching Shopify product variants

Important behavior

  • line changes use Shopify-facing actions
  • an order line cannot be removed if it would leave the order with no lines
  • editing permissions are limited by order status and user role

In the current code, general order editing is intentionally narrow:

  • Requester can edit their own order only when it is in needs_rework
  • CompanyAdmin can edit other editable orders

Comments

Each order also includes a Comments relation manager.

Current behavior

  • users can post comments on accessible orders
  • comment content supports rich text
  • users can edit or delete only their own comments
  • comments are shown newest first

Budget Status

The order detail page includes a budget-status widget.

It shows yearly and monthly budget checks for the current order based on the assigned location budget.

The list view also exposes:

  • a combined budget exceeded flag
  • a yearly exceeded flag
  • a monthly exceeded flag

Access Rules

The current policy logic is centered on:

  • who created the order
  • the user's role
  • whether the user is attached to the order location
  • the current order status

In practice:

  • creators can always view their own orders
  • Orderer and OrdererAdmin can view orders for their assigned locations
  • CompanyAdmin can view company orders across locations
  • BudgetAdmin is not granted draft-order viewing rights by DraftOrderPolicy

Workflow actions such as rework and Shopify confirmation are more restricted than plain viewing.

Policy-Based Workflow Rules

Reading directly from DraftOrderPolicy, the current workflow permissions are:

View

  • creator of the order: yes
  • Orderer attached to the order location: yes
  • OrdererAdmin attached to the order location: yes
  • CompanyAdmin: yes
  • BudgetAdmin: not explicitly allowed

Submit for Approval

The policy intends this to be for a Requester who:

  • created the order
  • is attached to the order location
  • is within budget
  • is working from draft or needs_rework

However, the current status condition in the policy is written so narrowly that this action may not appear in practice even when the workflow suggests it should.

Send to Rework

  • CompanyAdmin: allowed
  • Orderer attached to the order location: allowed
  • OrdererAdmin: not granted by this policy method
  • BudgetAdmin: not granted by this policy method

There is also a special restriction preventing the creator from sending their own order to rework when they are acting as OrdererAdmin or CompanyAdmin.

Confirm Order

  • CompanyAdmin: allowed
  • OrdererAdmin attached to the order location: allowed
  • Orderer attached to the order location: allowed only when the order is not budget-exceeded
  • Requester: not allowed
  • BudgetAdmin: not allowed

These role checks are stricter than the older generic approval language, so they are the rules to use when training users on the current build.