CampusDelivery

Project overview

JiRun (CampusDelivery) is a campus delivery platform developed by our ten-person team for a database course, with each member responsible for a business module. It supports food distribution, parcel collection and personal errands: users publish requests, couriers perform deliveries, and administrators manage services and dispatching.

The project covers the service lifecycle, from accounts, addresses, service types and courier qualification to task publishing, assignment, delivery and payment after receipt. It also includes reviews, complaints, refunds, courier settlements, auditing and reports. My work focused on assignment and delivery, connecting published requests with the couriers carrying out the service.

End-to-end business flow

Pages and permissions are organized around three roles: users, couriers and administrators. The main workflow is:

1. Publish a task. A user maintains a delivery address, selects a service type and provides the relevant task details. The task enters the waiting state.
2. Assign and deliver. Approved couriers claim tasks in the task hall; administrators can also assign or reassign them. The assigned courier updates pickup, delivery and arrival in sequence.
3. Confirm receipt and pay. The sender confirms receipt before proceeding to payment. Successful payment completes the task, and courier availability is updated according to their remaining active tasks.
4. Review and operate. Users can review the service, submit complaints or request refunds. Administrators handle after-sales requests, generate courier settlements, audit records and view reports.

Tasks, assignment records and payment records connect these modules. Their history supports subsequent reviews, settlement and auditing. My receipt-confirmation feature establishes the prerequisite for payment; another team member implemented payment, refunds and the final paid completion state.

Technology and application layers

The application uses C#, .NET 9, ASP.NET Core MVC (Model–View–Controller) and Oracle 19c. Razor views present forms and data; controllers receive requests; services handle permissions and business rules; repositories execute parameterized SQL; and a shared connection component manages Oracle connections. The database contains 24 business tables.

My module follows the same structure. A claim or status-update request must pass identity, qualification and current-state checks before the task, assignment record and status log are saved as one business operation. The page response needs to agree with the resulting database state.

My assignment and delivery-state work

From the task hall to receipt confirmation

As member 6, I developed the task hall, courier claiming, administrator assignment and reassignment, ordered delivery transitions, sender receipt confirmation, assignment records and status logs. My work covered pages, business logic and data access.

Delivery progresses through assigned, picked up, delivering and awaiting confirmation. Each step checks both the actor and the current state. Receipt confirmation then hands the task over to the payment workflow. Pages offer the next valid action, while the server enforces the same rules for unauthorized actions, repeated requests and attempts to skip stages.

Concurrent claiming and data consistency

Two couriers may try to claim the same task simultaneously. The integrated version uses database transactions and task-row locks to coordinate state checks, assignee updates, assignment records and status logs. An unsuccessful competing request receives a failure response. Checking the database result is part of verifying that a task has one valid assignment outcome.

Administrator assignment and reassignment also consider task state, courier qualification and whether the courier is the task’s sender. Reassignment adds an operation record and preserves the previous assignment history, making the handover traceable.

Multi-order workspace and reassignment improvements

In later iterations, I added multi-order claiming, active-task counts and FREE/BUSY classification based on active assignments. Couriers can work on several deliveries at once. Reassigning or completing payment for one task requires checking their other active tasks before updating availability.

I also added an assigned-task table, reassignment search, state filters and pagination to the administrator interface, with a dialog for searching and selecting a courier. This brings task and courier information into the dispatching workflow and reduces repeated navigation between pages.

Below is the original multi-order delivery workspace screenshot, using course test data:

Team collaboration and validation

My changes entered the team branch through pull requests, followed by further team refactoring and fixes. I tested my module in the integrated environment, checking page responses alongside task states, assignment records, logs and courier availability.

In September 2026, all nine manual cases, TC-ASSIGN-01 through TC-ASSIGN-09, passed in the deployed test environment, with screenshots and Oracle evidence. They covered normal and multi-order claiming, administrator assignment and reassignment, qualification restrictions, delivery transitions, concurrency and failure paths:

• Two independent sessions claimed the same task. One succeeded, and the database retained one assignment record and one corresponding transition log.
• After reassignment, I checked active-task counts and availability for both the original and new couriers.
• Self-assignment and invalid state-transition requests were rejected, with the task and logs retaining their previous state.

The project gave me a practical setting for understanding transactions, authorization and state transitions. One page action can affect several tables and determine what other roles can do next. Following those relationships across the complete workflow was a recurring part of my assignment-module work.

Repository ↗