Files

egg c8966477b9 feat: Initial commit - Task Reporter incident response system

Complete implementation of the production line incident response system (生產線異常即時反應系統) including:

Backend (FastAPI):
- User authentication with AD integration and session management
- Chat room management (create, list, update, members, roles)
- Real-time messaging via WebSocket (typing indicators, reactions)
- File storage with MinIO (upload, download, image preview)

Frontend (React + Vite):
- Authentication flow with token management
- Room list with filtering, search, and pagination
- Real-time chat interface with WebSocket
- File upload with drag-and-drop and image preview
- Member management and room settings
- Breadcrumb navigation
- 53 unit tests (Vitest)

Specifications:
- authentication: AD auth, sessions, JWT tokens
- chat-room: rooms, members, templates
- realtime-messaging: WebSocket, messages, reactions
- file-storage: MinIO integration, file management
- frontend-core: React SPA structure

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

2025-12-01 17:42:52 +08:00

9.4 KiB

Raw Blame History

Chat Room Management Capability

ADDED Requirements

Requirement: System Administrator Role

The system SHALL recognize ymirliu@panjit.com.tw as a system administrator with super-user privileges across all chat rooms, including the ability to override access controls, manage any room, and perform administrative operations.

Scenario: Identify system administrator

WHEN a user with email "ymirliu@panjit.com.tw" authenticates
THEN the system SHALL flag this user as a system administrator
AND grant elevated privileges for all room operations
AND log all admin actions for audit purposes

Scenario: Admin bypass room restrictions

WHEN a system administrator attempts any room operation
THEN the system SHALL allow the operation regardless of:
- Room membership status
- Room status (active, resolved, archived)
- Normal role restrictions
AND record the admin override in audit log

Requirement: Create Incident Room

The system SHALL allow authenticated users to create a new incident room with metadata including title, incident type, severity level, location, and description. Each room SHALL be assigned a unique identifier and timestamp upon creation.

Scenario: Create room for equipment failure incident

WHEN an authenticated user sends POST /api/rooms with body:

{
  "title": "Line 3 Conveyor Belt Stopped",
  "incident_type": "equipment_failure",
  "severity": "high",
  "location": "Building A, Line 3",
  "description": "Conveyor belt motor overheating, production halted"
}

THEN the system SHALL create a new incident_rooms record with:
- Unique room_id (UUID)
- Provided metadata fields
- Status set to "active"
- created_by set to current user's ID
- created_at timestamp
AND automatically add the creator as a room member with "owner" role
AND return status 201 with the room details including room_id

Scenario: Create room with missing required fields

WHEN a user attempts to create a room without required fields (title, incident_type)
THEN the system SHALL return status 400 with validation error details

Scenario: Create room without authentication

WHEN an unauthenticated request is sent to POST /api/rooms
THEN the system SHALL return status 401 with "Authentication required"

Requirement: List and Filter Incident Rooms

The system SHALL provide endpoints to list incident rooms with filtering capabilities by status, incident type, severity, date range, and user membership.

Scenario: List all active rooms for current user

WHEN an authenticated user sends GET /api/rooms?status=active
THEN the system SHALL return all active rooms where the user is a member
AND include room metadata (title, type, severity, member count, last activity)
AND sort by last_activity_at descending (most recent first)

Scenario: Filter rooms by incident type and date range

WHEN a user sends GET /api/rooms?incident_type=quality_issue&created_after=2025-01-01&created_before=2025-01-31
THEN the system SHALL return rooms matching ALL filter criteria
AND only include rooms where the user is a member

Scenario: Search rooms by title or description

WHEN a user sends GET /api/rooms?search=conveyor
THEN the system SHALL return rooms where title OR description contains "conveyor" (case-insensitive)
AND highlight matching terms in the response

Requirement: Manage Room Membership

The system SHALL allow room owners and members with appropriate permissions to add or remove members and assign roles (owner, editor, viewer). Room owners SHALL be able to transfer ownership to another member. System administrators SHALL have override capabilities for all membership operations.

Scenario: Add member to existing room

WHEN a room owner sends POST /api/rooms/{room_id}/members with:
```
{
  "user_id": "user123",
  "role": "editor"
}
```
THEN the system SHALL create a room_members record with specified role
AND update room's member_count
AND record added_by and added_at timestamp
AND return status 200 with updated member list

Scenario: Remove member from room

WHEN a room owner sends DELETE /api/rooms/{room_id}/members/{user_id}
THEN the system SHALL soft-delete the membership (set removed_at timestamp)
AND update room's member_count
AND return status 200

Scenario: Non-owner attempts to add member

WHEN a room member without owner role attempts to add another member
THEN the system SHALL return status 403 with "Insufficient permissions"
UNLESS the user is a system administrator, in which case the operation succeeds

Scenario: Change member role

WHEN a room owner sends PATCH /api/rooms/{room_id}/members/{user_id} with:
```
{
  "role": "viewer"
}
```
THEN the system SHALL update the member's role
AND record the change in audit log

Scenario: Transfer room ownership

WHEN a room owner sends POST /api/rooms/{room_id}/transfer-ownership with:
```
{
  "new_owner_id": "user456"
}
```
THEN the system SHALL verify the new owner is an existing room member
AND update the new owner's role to "owner"
AND change the previous owner's role to "editor"
AND record the ownership transfer in audit log with timestamp
AND return status 200 with updated member list

Scenario: Admin override - Add member to any room

WHEN a system administrator (ymirliu@panjit.com.tw) adds a member to any room
THEN the system SHALL allow the operation regardless of room membership
AND record the admin action in audit log

Requirement: Update Room Status and Metadata

The system SHALL allow room owners to update room metadata and transition room status through its lifecycle (active → resolved → archived).

Scenario: Mark room as resolved

WHEN a room owner sends PATCH /api/rooms/{room_id} with:

{
  "status": "resolved",
  "resolution_notes": "Replaced motor, production resumed"
}

THEN the system SHALL update status to "resolved"
AND set resolved_at timestamp
AND store resolution_notes
AND keep room accessible in read-only mode for members

Scenario: Update room metadata