Moladin Warehouse Management

An existing request deadline covered the time waiting for a warehouse response. Approval introduced a second failure mode: the destination had accepted the request, but the agent might never bring the car or BPKB to the warehouse. Treating both as one timeout would not identify which stage had stalled.

I extended the flow with a separate reservation deadline set when a request was approved. Repository queries distinguished expired pending requests from expired approved reservations, and separate scheduled services swept both groups every five minutes when cron processing was enabled.

Each cancellation wrote its own reject reason and remark, updated the approval state, created a detailed inventory log, and saved an inventory-history snapshot. Request and reservation windows were configured independently in hours through environment variables.

Separate scheduled services closed both stale states automatically and recorded whether the manager-response window or the post-approval arrival window had expired. The reason was recorded in approval and inventory history.

Borrow and regular-buyout paths calculated future custody deadlines. Adding calendar days could place a deadline on Sunday, when the warehouse was closed.

I added a shared helper that takes a start date, number of days, end-of-day behavior, and timezone. It calculates the result in the configured timezone and moves a Sunday result to Monday. Borrow and regular-buyout deadline paths both used the helper.

Those paths no longer returned a Sunday deadline, and the Sunday rule lived in one function. We checked the borrow and buyout paths by hand, feeding in start dates whose computed deadline landed on a Sunday and watching each one move to Monday. QA ran those checks with me. No regression test pins the rule down, so it is confirmed only for the cases we walked through. The helper did not model public holidays, which remained a separate unimplemented requirement.

A role did not establish authority over every warehouse. Physical check-in and check-out needed to be limited to administrators or staff related to the warehouse holding or receiving the item. Approval had a narrower delegation rule: a mapped warehouse coordinator could respond when the assigned destination manager was unavailable.

I adjusted the service checks around those relationships. Physical check-in and check-out verified the actor's warehouse association and explicitly excluded coordinators from performing those actions. The approval path accepted either the assigned manager or a coordinator mapped to the destination warehouse, while preventing an inactive manager from approving directly.

I also added manager and area-control-manager listing endpoints with role checks in the service layer instead of relying on the caller to filter unauthorized results.

Physical custody actions remained tied to the relevant warehouse, while delegated coordinators could handle the approval step without gaining check-in or check-out authority. QA and I walked the scenario on the development environment: checking in as an administrator, then as related staff, then confirming that a coordinator was refused the same action while still able to approve.

Whether the mobile app should offer a car, BPKB, or combined interwarehouse request depended on inventory state. Check-out depended on additional facts: the user's role and warehouse relationship, physical location, sale state, and approved borrowing state.

I returned those decisions as explicit capability flags in the inventory API. The interwarehouse create path enforced the same car, BPKB, and combined-request flags, so the response was not only presentation guidance. User-specific check-out flags applied the authorization and inventory conditions on the backend as well.

Mobile clients could render the actions returned by the backend, while requests were still validated against the same rules when submitted.