ALLPICK | Projects | So Jung Lee

Java / Spring Boot / React / JWT

Commits may appear as beancan0325, my previous GitHub username.

1. Project Overview and Design — a shopping platform for members, sellers, and admins

Team project | 2026.04 ~ 2026.05

ALLPICK is a shopping mall platform where members browse and order products, sellers register and manage products, and admins handle approvals, refunds, and inquiries. The same order or product data allows different actions depending on the role, so one wrongly exposed button can break a refund or seller-approval flow. I focused on admin and mypage flows where role permission, refund state, and seller status decide which operation is allowed.

My Contribution

Admin and mypage flows around refund state, seller status actions, request tokens, and backend guards.

Decision

Visible buttons and backend state transitions must share the same processable-state rule.

Verification

Code evidence shows frontend guards, token selection, and backend invalid-transition checks.

Limitation

The page shows implementation evidence, not measured performance or production traffic results.

Case 1. Enforcing refund transitions on the server, not only in buttons

Failure state: An admin can act on an invalid refund state or call the API directly to skip an intermediate step.
Decision: The UI exposes only state-valid actions, while the backend independently checks ALLOWED_TRANSITIONS. The screen guard improves usability; the service layer owns integrity.
Code evidence: Frontend AdminRefundPage.jsx approval/rejection guards and backend ClaimServiceImpl.java transition map and updateStatus.
Verification: ClaimServiceImplTest.java covers invalid transitions and attempts to change already completed claims.
Limitation: This is not a production throughput claim. The verified outcome is preventing invalid refund-state changes.

Case 2. Role and token boundaries across admins, sellers, and buyers

Failure state: A screen role and request token can drift apart, sending a member token to an admin endpoint or exposing another role's action.
Decision: Select role-specific tokens in the frontend request layer, then enforce URL and service rules with Spring Security. UI visibility is never treated as authorization.
Code evidence: Frontend api/index.js; backend SecurityConfig.java, BusinessException, ErrorCode, and GlobalExceptionHandler.
Verification: Role-specific flows and API error responses were checked together so failures return consistent error codes rather than ad-hoc strings.
Outcome: The frontend provides role-aware behavior while the backend remains the final authority.

Case 3. Keeping seller approval actions aligned with seller state

Failure state: An already approved or rejected seller can receive approval actions again, or the API can process the same decision twice.
Decision: Render buttons by seller state and allow approval or rejection only from PENDING on the backend.
Code evidence: Frontend AdminMemberPage.jsx; backend AdminSellerApprovalServiceImpl.java.
Verification: AdminSellerApprovalServiceImplTest.java covers pending-only lists, non-pending approval/rejection failures, and status-toggle restrictions.
Outcome: ALLPICK is presented as a role-and-state consistency problem, not merely a CRUD storefront.

ALLPICK refund state flow diagram — **Refund state flow**
User request, seller confirmation, and admin final approval/rejection are separated.

ALLPICK role token routing table — **Role-token routing**
Admin, seller, and buyer requests select different tokens before backend checks.

ALLPICK state action matrix — **State-action matrix**
Visible admin actions change by PENDING, APPROVED, SUSPENDED, and REJECTED states.

2. Key Features

Seller handoff before admin decision

Admin approval/rejection is available only after seller confirmation, and both frontend and backend use the same processable state.

Request-specific token selection

Admin, seller, and user requests can share an axios layer while still choosing the right token for each request type.

Seller status action control

PENDING, APPROVED, and SUSPENDED states determine which admin buttons are visible and which service action is allowed.

Backend validation behind UI guards

Invalid refund transitions and seller-state actions are rejected in the service layer even if the UI is bypassed.

3. Project Problem-Solution

Refund Flow

Keeping seller confirmation before admin refund completion

Problem

If admins complete refunds directly, the seller confirmation step disappears.

Cause

The refund responsibility was not split clearly between user request, seller confirmation, and admin final decision.

Fix

Split the flow into SUBMITTED -> IN_PROGRESS -> COMPLETED/REJECTED state transitions.

Result

Admins can approve or reject only IN_PROGRESS refunds, and the backend blocks invalid transitions.

Role Token

Preventing admin, seller, and buyer requests from using the wrong token

Problem

Different roles can pass through a shared frontend request layer and accidentally call APIs with the wrong token.

Cause

Admin, seller, and member permissions differ, but many request flows share similar frontend plumbing.

Fix

Select the admin, seller, or member token based on request intent before backend authorization runs.

Result

The backend can apply role-specific authorization consistently even when the UI flow looks similar.

Admin State Guard

Blocking admin actions that do not match seller status

Problem

Already approved or suspended sellers could receive actions that no longer match their state.

Cause

PENDING, APPROVED, and SUSPENDED states allow different admin actions, but UI and server checks can drift apart.

Fix

Split button visibility by seller state and add backend guards for pending-only or transition-specific actions.

Result

Even if the UI is bypassed, already-processed seller states do not accept invalid approve/reject requests.

4. Screens and Code Evidence

ALLPICK refund approval guard code evidence — **Refund guard**
Admin refund buttons and backend transitions share the same processable status.

ALLPICK refund state action button rendering code evidence — **Processable-state buttons**
Approve/reject buttons render only when the refund is in IN_PROGRESS.

ALLPICK backend refund transition guard code evidence — **Backend transition guard**
Invalid refund state transitions are rejected in the service layer.

ALLPICK role token assignment code evidence — **Token selection**
The API layer routes requests to the correct token before backend authorization.

ALLPICK seller state button control code evidence — **Status control**
APPROVED and SUSPENDED states switch the visible suspend/reactivate action.

ALLPICK seller pending-state guard code evidence — **PENDING-only guard**
Already-processed sellers cannot be approved or rejected again.

5. Collaboration Process

Ownership boundaries

My work focused on my page and admin page flows, while touching order/refund areas through PR notes.

Feature branches

API changes, screen state, and backend validation were reviewed through feature-scoped pull requests.

Code review

State transitions, ErrorCode naming, controller/service validation, and tests were reviewed together.

Labels and releases

Team GitHub issues, labels, and releases make the change type and completed scope easier to inspect.