feat: Add Chat UX improvements with notifications and @mention support
- Add ActionBar component with expandable toolbar for mobile - Add @mention functionality with autocomplete dropdown - Add browser notification system (push, sound, vibration) - Add NotificationSettings modal for user preferences - Add mention badges on room list cards - Add ReportPreview with Markdown rendering and copy/download - Add message copy functionality with hover actions - Add backend mentions field to messages with Alembic migration - Add lots field to rooms, remove templates - Optimize WebSocket database session handling - Various UX polish (animations, accessibility) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
egg
@@ -21,9 +21,9 @@ The system SHALL recognize ymirliu@panjit.com.tw as a system administrator with
|
||||
- **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.
|
||||
The system SHALL allow authenticated users to create a new incident room with metadata including title, incident type, severity level, location, description, and optional LOT batch numbers. Each room SHALL be assigned a unique identifier and timestamp upon creation.
|
||||
|
||||
#### Scenario: Create room for equipment failure incident
|
||||
#### Scenario: Create room with LOT numbers
|
||||
- **WHEN** an authenticated user sends `POST /api/rooms` with body:
|
||||
```json
|
||||
{
|
||||
@@ -31,25 +31,18 @@ The system SHALL allow authenticated users to create a new incident room with me
|
||||
"incident_type": "equipment_failure",
|
||||
"severity": "high",
|
||||
"location": "Building A, Line 3",
|
||||
"description": "Conveyor belt motor overheating, production halted"
|
||||
"description": "Conveyor belt motor overheating, production halted",
|
||||
"lots": ["LOT-2024-001"]
|
||||
}
|
||||
```
|
||||
- **THEN** the system SHALL create a new incident_rooms record with:
|
||||
- Unique room_id (UUID)
|
||||
- Provided metadata fields
|
||||
- Provided metadata fields including lots
|
||||
- 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"
|
||||
- **AND** return status 201 with the room details including room_id and lots
|
||||
|
||||
### 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. The system SHALL automatically exclude rooms with ARCHIVED status from listing results for non-admin users, ensuring archived rooms are only visible to system administrators.
|
||||
@@ -121,44 +114,21 @@ The system SHALL allow room owners and members with appropriate permissions to a
|
||||
- **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).
|
||||
The system SHALL allow room owners and editors to update room metadata including LOT batch numbers, and allow owners to 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:
|
||||
```json
|
||||
{
|
||||
"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
|
||||
#### Scenario: Update room metadata with LOT
|
||||
- **WHEN** a room owner sends `PATCH /api/rooms/{room_id}` with:
|
||||
```json
|
||||
{
|
||||
"severity": "critical",
|
||||
"description": "Updated: Fire hazard detected"
|
||||
"description": "Updated: Fire hazard detected",
|
||||
"lots": ["LOT-2024-001", "LOT-2024-002"]
|
||||
}
|
||||
```
|
||||
- **THEN** the system SHALL update only the provided fields
|
||||
- **THEN** the system SHALL update only the provided fields including lots
|
||||
- **AND** record the update in room_activity log
|
||||
- **AND** set last_updated_at timestamp
|
||||
|
||||
#### Scenario: Archive resolved room
|
||||
- **WHEN** a room owner sends `PATCH /api/rooms/{room_id}` with status "archived"
|
||||
- **AND** the room is already in "resolved" status
|
||||
- **THEN** the system SHALL update status to "archived"
|
||||
- **AND** set archived_at timestamp
|
||||
- **AND** make room read-only for all members
|
||||
|
||||
#### Scenario: Invalid status transition
|
||||
- **WHEN** attempting to change status from "active" directly to "archived"
|
||||
- **THEN** the system SHALL return status 400 with "Invalid status transition"
|
||||
|
||||
### Requirement: Room Access Control
|
||||
The system SHALL enforce role-based access control for all room operations based on user membership and assigned roles. System administrators SHALL have full access to all rooms regardless of membership status.
|
||||
|
||||
@@ -188,31 +158,6 @@ The system SHALL enforce role-based access control for all room operations based
|
||||
- **THEN** the system SHALL return ALL rooms in the system, not just rooms where admin is a member
|
||||
- **AND** include an "is_admin_view" flag in the response
|
||||
|
||||
### Requirement: Room Templates
|
||||
The system SHALL support predefined room templates for common incident types to streamline room creation with preset metadata and initial members.
|
||||
|
||||
#### Scenario: Create room from template
|
||||
- **WHEN** a user sends `POST /api/rooms` with:
|
||||
```json
|
||||
{
|
||||
"template": "equipment_failure",
|
||||
"title": "Molding Machine #5 Down",
|
||||
"location": "Building B"
|
||||
}
|
||||
```
|
||||
- **THEN** the system SHALL create room with:
|
||||
- Preset incident_type from template
|
||||
- Default severity level from template
|
||||
- Auto-assigned team members based on template configuration
|
||||
- Template-specific metadata fields
|
||||
|
||||
#### Scenario: List available templates
|
||||
- **WHEN** a user sends `GET /api/room-templates`
|
||||
- **THEN** the system SHALL return available templates with:
|
||||
- Template name and description
|
||||
- Default values for each template
|
||||
- Required additional fields
|
||||
|
||||
### Requirement: Admin Permanent Room Deletion
|
||||
The system SHALL provide system administrators with the ability to permanently delete rooms, including all associated data (members, messages, files, reports). This operation is irreversible and restricted to system administrators only.
|
||||
|
||||
@@ -260,3 +205,95 @@ The system SHALL hide rooms with ARCHIVED status from non-admin users in all lis
|
||||
- **THEN** the system SHALL return all rooms regardless of status
|
||||
- **AND** include archived rooms in the response
|
||||
|
||||
### Requirement: LOT Batch Number Tracking
|
||||
The system SHALL support tracking multiple LOT (batch numbers) associated with each incident room. LOT information helps identify affected product batches for quality traceability and recall purposes.
|
||||
|
||||
#### Scenario: Create room with LOT numbers
|
||||
- **WHEN** an authenticated user sends `POST /api/rooms` with body:
|
||||
```json
|
||||
{
|
||||
"title": "Quality Issue on Line 3",
|
||||
"incident_type": "quality_issue",
|
||||
"severity": "high",
|
||||
"location": "Building A",
|
||||
"lots": ["LOT-2024-001", "LOT-2024-002"]
|
||||
}
|
||||
```
|
||||
- **THEN** the system SHALL create the room with the provided LOT numbers
|
||||
- **AND** store lots as a JSON array in the database
|
||||
- **AND** return the room details including the lots array
|
||||
|
||||
#### Scenario: Create room without LOT numbers
|
||||
- **WHEN** an authenticated user creates a room without specifying lots
|
||||
- **THEN** the system SHALL create the room with an empty lots array
|
||||
- **AND** allow lots to be added later via update
|
||||
|
||||
#### Scenario: Update room LOT numbers
|
||||
- **WHEN** an authenticated user with editor or owner role sends `PATCH /api/rooms/{room_id}` with:
|
||||
```json
|
||||
{
|
||||
"lots": ["LOT-2024-001", "LOT-2024-002", "LOT-2024-003"]
|
||||
}
|
||||
```
|
||||
- **THEN** the system SHALL replace the existing lots with the new array
|
||||
- **AND** update last_updated_at timestamp
|
||||
- **AND** return the updated room details
|
||||
|
||||
#### Scenario: Add single LOT to existing room
|
||||
- **WHEN** an authenticated user with editor or owner role sends `POST /api/rooms/{room_id}/lots` with:
|
||||
```json
|
||||
{
|
||||
"lot": "LOT-2024-004"
|
||||
}
|
||||
```
|
||||
- **THEN** the system SHALL append the LOT to the existing lots array
|
||||
- **AND** prevent duplicate LOT entries
|
||||
- **AND** return the updated lots array
|
||||
|
||||
#### Scenario: Remove single LOT from room
|
||||
- **WHEN** an authenticated user with editor or owner role sends `DELETE /api/rooms/{room_id}/lots/{lot_id}`
|
||||
- **THEN** the system SHALL remove the specified LOT from the array
|
||||
- **AND** return the updated lots array
|
||||
|
||||
#### Scenario: Viewer cannot modify LOT numbers
|
||||
- **WHEN** a user with viewer role attempts to update LOT numbers
|
||||
- **THEN** the system SHALL return status 403 with "Insufficient permissions"
|
||||
|
||||
#### Scenario: LOT numbers displayed in room details
|
||||
- **WHEN** a user sends `GET /api/rooms/{room_id}`
|
||||
- **THEN** the response SHALL include the lots array
|
||||
- **AND** lots SHALL be returned in the order they were added
|
||||
|
||||
---
|
||||
|
||||
### Requirement: Action Bar Layout
|
||||
The chat room interface SHALL provide an action bar near the message input area for quick access to common operations.
|
||||
|
||||
#### Scenario: Action bar displays common actions
|
||||
- **WHEN** user views a chat room
|
||||
- **THEN** an action bar is displayed above or beside the message input
|
||||
- **AND** the action bar includes: upload file, generate report, add member buttons
|
||||
|
||||
#### Scenario: Action bar toggle on mobile
|
||||
- **WHEN** user is on a mobile device
|
||||
- **THEN** the action bar buttons can be collapsed/expanded
|
||||
- **AND** a single toggle button reveals the full action options
|
||||
|
||||
### Requirement: Message Copy Action
|
||||
Users SHALL be able to copy individual message content to clipboard.
|
||||
|
||||
#### Scenario: Copy message content
|
||||
- **WHEN** user hovers over a message
|
||||
- **THEN** a copy button appears
|
||||
- **AND** clicking the button copies the message content to clipboard
|
||||
- **AND** a success toast notification is shown
|
||||
|
||||
### Requirement: Notification Settings
|
||||
Users SHALL be able to configure notification preferences for the chat room.
|
||||
|
||||
#### Scenario: Configure notification settings
|
||||
- **WHEN** user accesses notification settings
|
||||
- **THEN** user can enable/disable sound notifications
|
||||
- **AND** user can enable/disable browser push notifications
|
||||
- **AND** user can enable/disable vibration (on supported devices)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user