feat: Add mobile responsive layout, open room access, and admin room management
Mobile Responsive Layout: - Add useMediaQuery, useIsMobile, useIsTablet, useIsDesktop hooks for device detection - Create MobileHeader component with hamburger menu and action drawer - Create BottomToolbar for mobile navigation (Files, Members) - Create SlidePanel component for full-screen mobile sidebars - Update RoomDetail.tsx with mobile/desktop conditional rendering - Update RoomList.tsx with single-column grid and touch-friendly buttons - Add CSS custom properties for safe areas and touch targets (min 44px) - Add mobile viewport meta tags for notched devices Open Room Access: - All authenticated users can view all rooms (not just their own) - Users can join active rooms they're not members of - Add is_member field to room responses - Update room list API to return all rooms by default Admin Room Management: - Add permanent delete functionality for system admins - Add delete confirmation dialog with room title verification - Broadcast room deletion via WebSocket to connected users - Add users search API for adding members 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
egg
@@ -0,0 +1,31 @@
|
||||
# Proposal: Add Open Room Access
|
||||
|
||||
## Summary
|
||||
Modify the room access model to allow all authenticated users to view and self-join rooms, while maintaining role-based permissions for room operations.
|
||||
|
||||
## Motivation
|
||||
The current room model requires explicit invitation for users to see and join rooms. This creates friction in incident response scenarios where speed is critical. Users should be able to:
|
||||
1. Discover all active incidents without needing an invitation
|
||||
2. Self-join rooms to contribute or observe
|
||||
3. Have their role upgraded by existing members
|
||||
|
||||
## Scope
|
||||
|
||||
### Backend Changes (chat-room spec)
|
||||
1. **Public Room Listing**: All authenticated users can view all rooms (not just their own)
|
||||
2. **Self-Join Mechanism**: New endpoint `POST /api/rooms/{room_id}/join` for self-joining as VIEWER
|
||||
3. **Role Upgrade Permission**: EDITOR role gains permission to upgrade VIEWER → EDITOR
|
||||
|
||||
### Frontend Changes (frontend-core spec)
|
||||
1. **Member Search**: Add user search functionality when inviting/managing members
|
||||
2. **Password Visibility Toggle**: Add show/hide password button on login form
|
||||
3. **Join Room Button**: Display "Join" button for rooms where user is not a member
|
||||
|
||||
## Out of Scope
|
||||
- Creating private/invite-only room types (future enhancement)
|
||||
- Role downgrade by EDITOR (only OWNER can downgrade)
|
||||
- Member removal by EDITOR (only OWNER can remove)
|
||||
|
||||
## Related Specs
|
||||
- `chat-room`: Room membership and access control
|
||||
- `frontend-core`: Login and member management UI
|
||||
@@ -0,0 +1,103 @@
|
||||
# chat-room Specification Delta
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: List and Filter Incident Rooms
|
||||
The system SHALL provide endpoints to list incident rooms with filtering capabilities. All authenticated users SHALL be able to view all rooms regardless of membership status.
|
||||
|
||||
#### Scenario: List all rooms for authenticated user (MODIFIED)
|
||||
- **WHEN** an authenticated user sends `GET /api/rooms`
|
||||
- **THEN** the system SHALL return ALL rooms in the system
|
||||
- **AND** include room metadata (title, type, severity, member count, last activity)
|
||||
- **AND** include `is_member` flag indicating if user is a member
|
||||
- **AND** include `current_user_role` (null if not a member)
|
||||
- **AND** sort by last_activity_at descending (most recent first)
|
||||
|
||||
#### Scenario: Filter rooms with membership filter
|
||||
- **WHEN** a user sends `GET /api/rooms?my_rooms=true`
|
||||
- **THEN** the system SHALL return only rooms where the user is a member
|
||||
- **AND** apply any other filters (status, incident_type, etc.)
|
||||
|
||||
### Requirement: Room Self-Join
|
||||
The system SHALL allow any authenticated user to join a room as a VIEWER without requiring an invitation.
|
||||
|
||||
#### Scenario: Self-join room as viewer
|
||||
- **WHEN** an authenticated non-member sends `POST /api/rooms/{room_id}/join`
|
||||
- **THEN** the system SHALL create a room_members record with role "viewer"
|
||||
- **AND** update room's member_count
|
||||
- **AND** record added_by as the joining user's own ID
|
||||
- **AND** record added_at timestamp
|
||||
- **AND** return status 200 with the new membership details
|
||||
|
||||
#### Scenario: Self-join when already a member
|
||||
- **WHEN** an existing member sends `POST /api/rooms/{room_id}/join`
|
||||
- **THEN** the system SHALL return status 409 with "Already a member of this room"
|
||||
- **AND** include current membership details in response
|
||||
|
||||
#### Scenario: Self-join archived room
|
||||
- **WHEN** a user attempts to join an archived room
|
||||
- **THEN** the system SHALL return status 400 with "Cannot join archived room"
|
||||
|
||||
### Requirement: Manage Room Membership (MODIFIED)
|
||||
The system SHALL allow room owners and editors to manage members. Editors SHALL be able to upgrade VIEWER members to EDITOR role but cannot downgrade or remove members.
|
||||
|
||||
#### Scenario: Editor upgrades viewer to editor (NEW)
|
||||
- **WHEN** a room editor sends `PATCH /api/rooms/{room_id}/members/{user_id}` with:
|
||||
```json
|
||||
{
|
||||
"role": "editor"
|
||||
}
|
||||
```
|
||||
- **AND** the target user is currently a viewer
|
||||
- **THEN** the system SHALL update the member's role to "editor"
|
||||
- **AND** record the change in audit log
|
||||
- **AND** return status 200 with updated member details
|
||||
|
||||
#### Scenario: Editor attempts to downgrade member
|
||||
- **WHEN** a room editor attempts to change a member's role to a lower role (editor → viewer)
|
||||
- **THEN** the system SHALL return status 403 with "Editors can only upgrade members"
|
||||
|
||||
#### Scenario: Editor attempts to remove member
|
||||
- **WHEN** a room editor attempts to remove a member
|
||||
- **THEN** the system SHALL return status 403 with "Only owner can remove members"
|
||||
|
||||
#### Scenario: Editor attempts to set owner role
|
||||
- **WHEN** a room editor attempts to change a member's role to "owner"
|
||||
- **THEN** the system SHALL return status 403 with "Only owner can transfer ownership"
|
||||
|
||||
### Requirement: Room Access Control (MODIFIED)
|
||||
The system SHALL enforce role-based access control. Non-members can view room metadata in listings but must join to access room content.
|
||||
|
||||
#### Scenario: Non-member views room in list (NEW)
|
||||
- **WHEN** a non-member requests room list via `GET /api/rooms`
|
||||
- **THEN** the system SHALL include all rooms with basic metadata
|
||||
- **AND** set `is_member: false` and `current_user_role: null` for non-member rooms
|
||||
|
||||
#### Scenario: Non-member attempts to access room details
|
||||
- **WHEN** a non-member sends `GET /api/rooms/{room_id}`
|
||||
- **THEN** the system SHALL return status 403 with "Join room to access details"
|
||||
- **AND** include a `join_url` field pointing to the join endpoint
|
||||
|
||||
#### Scenario: Non-member attempts to access room messages
|
||||
- **WHEN** a non-member sends `GET /api/rooms/{room_id}/messages`
|
||||
- **THEN** the system SHALL return status 403 with "Not a member of this room"
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: User Directory Search
|
||||
The system SHALL provide a searchable user directory for member management, sourced from the users table (populated during login).
|
||||
|
||||
#### Scenario: Search users by name or email
|
||||
- **WHEN** a room owner or editor sends `GET /api/users/search?q=john`
|
||||
- **THEN** the system SHALL return users matching the search query
|
||||
- **AND** search both display_name and user_id (email) fields
|
||||
- **AND** return at most 20 results
|
||||
- **AND** include user_id and display_name for each result
|
||||
|
||||
#### Scenario: Search with empty query
|
||||
- **WHEN** a user sends `GET /api/users/search` without query parameter
|
||||
- **THEN** the system SHALL return status 400 with "Search query required"
|
||||
|
||||
#### Scenario: Search returns no results
|
||||
- **WHEN** a search query matches no users
|
||||
- **THEN** the system SHALL return an empty array with status 200
|
||||
@@ -0,0 +1,116 @@
|
||||
# frontend-core Specification Delta
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: User Authentication Interface (MODIFIED)
|
||||
The frontend SHALL provide a login interface with password visibility toggle.
|
||||
|
||||
#### Scenario: Password visibility toggle (NEW)
|
||||
- **WHEN** a user is on the login page
|
||||
- **THEN** the system SHALL:
|
||||
- Display password field with masked input by default
|
||||
- Show a toggle button (eye icon) next to the password field
|
||||
- Toggle password visibility when button is clicked
|
||||
- Change icon to indicate current state (eye/eye-slash)
|
||||
|
||||
#### Scenario: Password field default state
|
||||
- **WHEN** the login page loads
|
||||
- **THEN** the password field SHALL be in masked (hidden) state
|
||||
- **AND** the toggle button SHALL show "show password" icon
|
||||
|
||||
### Requirement: Incident Room List (MODIFIED)
|
||||
The frontend SHALL display all rooms with join capability for non-member rooms.
|
||||
|
||||
#### Scenario: Display all rooms including non-member rooms (MODIFIED)
|
||||
- **WHEN** a logged-in user navigates to the room list page
|
||||
- **THEN** the system SHALL:
|
||||
- Fetch all rooms from `GET /api/rooms`
|
||||
- Display rooms as cards with title, status, severity, and timestamp
|
||||
- Show "Member" badge for rooms where user is a member
|
||||
- Show "Join" button for rooms where user is not a member
|
||||
- Order by last activity (most recent first)
|
||||
|
||||
#### Scenario: Filter to show only my rooms
|
||||
- **WHEN** a user toggles "My Rooms Only" filter
|
||||
- **THEN** the system SHALL:
|
||||
- Add `?my_rooms=true` parameter to room list request
|
||||
- Display only rooms where user is a member
|
||||
- Hide the filter when active (or show "Show All" toggle)
|
||||
|
||||
#### Scenario: Join room from list
|
||||
- **WHEN** a user clicks "Join" button on a room card
|
||||
- **THEN** the system SHALL:
|
||||
- Send `POST /api/rooms/{room_id}/join`
|
||||
- Update card to show "Member" badge on success
|
||||
- Navigate to room detail page
|
||||
- Show error message on failure
|
||||
|
||||
### Requirement: Member Management Interface (MODIFIED)
|
||||
The frontend SHALL provide member management with user search functionality.
|
||||
|
||||
#### Scenario: Add member with search (MODIFIED)
|
||||
- **WHEN** an owner or editor opens the add member dialog
|
||||
- **THEN** the system SHALL:
|
||||
- Display a searchable user input field
|
||||
- Query `GET /api/users/search?q={query}` as user types (debounced)
|
||||
- Display matching users in a dropdown list
|
||||
- Allow selection of a user from the list
|
||||
- Show role selection dropdown (default: viewer)
|
||||
- Allow role upgrade to editor for existing viewers
|
||||
|
||||
#### Scenario: Search users while adding member
|
||||
- **WHEN** a user types in the member search field
|
||||
- **THEN** the system SHALL:
|
||||
- Wait 300ms after last keystroke (debounce)
|
||||
- Show loading indicator
|
||||
- Display search results with display_name and email
|
||||
- Allow clicking to select a user
|
||||
|
||||
#### Scenario: No search results
|
||||
- **WHEN** user search returns no results
|
||||
- **THEN** the system SHALL:
|
||||
- Display "No users found" message
|
||||
- Suggest checking the spelling or trying a different search
|
||||
|
||||
#### Scenario: Editor upgrades viewer to editor (NEW)
|
||||
- **WHEN** an editor views a viewer member's options
|
||||
- **THEN** the system SHALL:
|
||||
- Display "Upgrade to Editor" option
|
||||
- Submit role change to `PATCH /api/rooms/{room_id}/members/{user_id}`
|
||||
- Update member display on success
|
||||
- Show error message on failure
|
||||
|
||||
#### Scenario: Editor cannot downgrade or remove (NEW)
|
||||
- **WHEN** an editor views member management options
|
||||
- **THEN** the system SHALL:
|
||||
- Hide "Remove" option for all members
|
||||
- Hide role downgrade options
|
||||
- Only show "Upgrade to Editor" for viewers
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Room Join Interface
|
||||
The frontend SHALL provide UI for non-members to join rooms.
|
||||
|
||||
#### Scenario: View room as non-member
|
||||
- **WHEN** a non-member navigates to a room they found in the list
|
||||
- **THEN** the system SHALL:
|
||||
- Display room basic info (title, status, severity)
|
||||
- Show "Join Room" prominent button
|
||||
- Display message explaining they need to join to view content
|
||||
- Show member count and activity summary
|
||||
|
||||
#### Scenario: Join room from detail page
|
||||
- **WHEN** a non-member clicks "Join Room" button
|
||||
- **THEN** the system SHALL:
|
||||
- Send `POST /api/rooms/{room_id}/join`
|
||||
- Reload room with full content access on success
|
||||
- Display success toast "You have joined the room as Viewer"
|
||||
- Show error message on failure
|
||||
|
||||
#### Scenario: Cannot join archived room
|
||||
- **WHEN** a non-member views an archived room
|
||||
- **THEN** the system SHALL:
|
||||
- Display "This room is archived" message
|
||||
- Hide the "Join Room" button
|
||||
- Show room metadata in read-only mode
|
||||
@@ -0,0 +1,89 @@
|
||||
# Tasks: Add Open Room Access
|
||||
|
||||
## Phase 1: Backend - Room Visibility & Self-Join
|
||||
|
||||
### 1.1 Modify room listing to show all rooms
|
||||
- [x] Update `room_service.list_user_rooms()` to return all rooms for authenticated users
|
||||
- [x] Add `is_member` and `current_user_role` fields to room response
|
||||
- [x] Add `my_rooms` query parameter filter
|
||||
- [x] Update room list schema to include new fields
|
||||
- [x] Write unit tests for modified listing behavior
|
||||
|
||||
### 1.2 Implement self-join endpoint
|
||||
- [x] Create `POST /api/rooms/{room_id}/join` endpoint
|
||||
- [x] Add validation for already-member case (return 409)
|
||||
- [x] Add validation for archived room case (return 400)
|
||||
- [x] Create membership with role="viewer" and added_by=self
|
||||
- [x] Update room member_count on join
|
||||
- [x] Write integration tests for self-join
|
||||
|
||||
### 1.3 Modify role change permissions for editors
|
||||
- [x] Update `membership_service.check_user_permission()` for role changes
|
||||
- [x] Allow EDITOR to upgrade VIEWER → EDITOR
|
||||
- [x] Deny EDITOR from downgrading (editor→viewer) or removing members
|
||||
- [x] Deny EDITOR from setting owner role
|
||||
- [x] Write unit tests for permission matrix changes
|
||||
|
||||
### 1.4 Implement user search endpoint
|
||||
- [x] Create `GET /api/users/search` endpoint
|
||||
- [x] Query users table by display_name and user_id (email)
|
||||
- [x] Return max 20 results
|
||||
- [x] Require minimum query length
|
||||
- [x] Write tests for search functionality
|
||||
|
||||
## Phase 2: Frontend - Login & Room List
|
||||
|
||||
### 2.1 Add password visibility toggle to login
|
||||
- [x] Add eye/eye-slash toggle button to password field
|
||||
- [x] Toggle input type between "password" and "text"
|
||||
- [x] Update button icon based on visibility state
|
||||
- [x] Ensure toggle works with keyboard accessibility
|
||||
|
||||
### 2.2 Update room list for all-rooms view
|
||||
- [x] Fetch all rooms (remove member-only filter default)
|
||||
- [x] Display "Member" badge for member rooms
|
||||
- [x] Display "Join" button for non-member rooms
|
||||
- [x] Add "My Rooms Only" filter toggle
|
||||
- [x] Handle join action with optimistic update
|
||||
|
||||
### 2.3 Create room join preview for non-members
|
||||
- [x] Create restricted view for non-member room access
|
||||
- [x] Show room metadata but not content
|
||||
- [x] Display prominent "Join Room" button
|
||||
- [x] Handle join with success toast and page reload
|
||||
|
||||
## Phase 3: Frontend - Member Management
|
||||
|
||||
### 3.1 Add user search to member management
|
||||
- [x] Create searchable user input component
|
||||
- [x] Implement debounced search (300ms)
|
||||
- [x] Display search results with name and email
|
||||
- [x] Handle empty results state
|
||||
- [x] Wire up to `GET /api/users/search`
|
||||
|
||||
### 3.2 Update member role change UI for editors
|
||||
- [x] Show "Upgrade to Editor" for viewers (when current user is editor)
|
||||
- [x] Hide remove option for editors
|
||||
- [x] Hide downgrade options for editors
|
||||
- [x] Keep full controls visible for owners
|
||||
|
||||
## Phase 4: Testing & Validation
|
||||
|
||||
### 4.1 Backend integration tests
|
||||
- [x] Test room listing shows all rooms
|
||||
- [x] Test self-join creates viewer membership
|
||||
- [x] Test editor can upgrade but not downgrade
|
||||
- [x] Test user search returns correct results
|
||||
|
||||
### 4.2 Frontend E2E tests
|
||||
- [x] Test password visibility toggle
|
||||
- [x] Test room list shows join buttons
|
||||
- [x] Test self-join flow
|
||||
- [x] Test member search and add flow
|
||||
- [x] Test editor role limitations
|
||||
|
||||
## Validation Checklist
|
||||
- [x] Run `openspec validate add-open-room-access --strict`
|
||||
- [x] All existing tests pass
|
||||
- [x] New tests cover all scenarios
|
||||
- [x] Manual testing of full user flow
|
||||
@@ -0,0 +1,32 @@
|
||||
# Proposal: Add Admin Room Management
|
||||
|
||||
## Why
|
||||
|
||||
Currently, rooms can only be soft-deleted (archived) and non-admin users can still see archived rooms when filtering. This creates two issues:
|
||||
|
||||
1. **No permanent deletion**: Archived rooms remain in the database indefinitely, and there's no way to completely remove sensitive or test data.
|
||||
2. **Archived rooms visible to all**: Non-admin users can view archived rooms by changing the status filter, which may expose historical data that should be hidden from general users.
|
||||
|
||||
## What Changes
|
||||
|
||||
### 1. Admin-Only Permanent Room Deletion
|
||||
- Add new endpoint `DELETE /api/rooms/{room_id}/permanent`
|
||||
- Only system administrator (ymirliu@panjit.com.tw) can execute
|
||||
- Cascading hard delete of all related data (members, messages, files, reports)
|
||||
- Clean up MinIO storage for associated files
|
||||
- Broadcast WebSocket disconnect to active connections
|
||||
|
||||
### 2. Hide Archived Rooms from Non-Admin Users
|
||||
- Modify room listing to exclude ARCHIVED status for non-admin users
|
||||
- Even "All Status" filter will not show archived rooms for regular users
|
||||
- Admin users retain full visibility of all room statuses
|
||||
- Remove "Archived" option from frontend status filter for non-admin users
|
||||
|
||||
## Related Specs
|
||||
- `chat-room`: Room access control and deletion
|
||||
- `frontend-core`: Room list filtering UI
|
||||
|
||||
## Out of Scope
|
||||
- Batch deletion of multiple rooms
|
||||
- Scheduled auto-deletion of old archived rooms
|
||||
- Restore deleted rooms from backup
|
||||
@@ -0,0 +1,66 @@
|
||||
# chat-room Specification Delta
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### 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.
|
||||
|
||||
#### Scenario: Admin permanently deletes a room
|
||||
- **WHEN** a system administrator sends `DELETE /api/rooms/{room_id}/permanent`
|
||||
- **THEN** the system SHALL verify the user is ymirliu@panjit.com.tw
|
||||
- **AND** hard delete the room record from incident_rooms table
|
||||
- **AND** cascade delete all room_members records
|
||||
- **AND** cascade delete all messages and related reactions/edit_history
|
||||
- **AND** cascade delete all room_files records
|
||||
- **AND** delete associated files from MinIO storage
|
||||
- **AND** cascade delete all generated_reports records
|
||||
- **AND** delete associated report files from MinIO storage
|
||||
- **AND** broadcast disconnect event to any active WebSocket connections in the room
|
||||
- **AND** return status 200 with `{"message": "Room permanently deleted"}`
|
||||
|
||||
#### Scenario: Non-admin attempts permanent deletion
|
||||
- **WHEN** a non-admin user sends `DELETE /api/rooms/{room_id}/permanent`
|
||||
- **THEN** the system SHALL return status 403 with "Only system administrators can permanently delete rooms"
|
||||
|
||||
#### Scenario: Permanent delete non-existent room
|
||||
- **WHEN** a system administrator sends `DELETE /api/rooms/{room_id}/permanent` for a non-existent room
|
||||
- **THEN** the system SHALL return status 404 with "Room not found"
|
||||
|
||||
### Requirement: Hide Archived Rooms from Non-Admin Users
|
||||
The system SHALL hide rooms with ARCHIVED status from non-admin users in all listing operations, ensuring historical/archived data is only visible to system administrators.
|
||||
|
||||
#### Scenario: Non-admin lists rooms with any filter
|
||||
- **WHEN** a non-admin user sends `GET /api/rooms` with any status filter (including no filter)
|
||||
- **THEN** the system SHALL exclude all rooms with status "archived" from the response
|
||||
- **AND** only return rooms with status "active" or "resolved"
|
||||
|
||||
#### Scenario: Non-admin explicitly requests archived rooms
|
||||
- **WHEN** a non-admin user sends `GET /api/rooms?status=archived`
|
||||
- **THEN** the system SHALL return an empty list
|
||||
- **AND** return total count of 0
|
||||
|
||||
#### Scenario: Admin can view archived rooms
|
||||
- **WHEN** a system administrator sends `GET /api/rooms?status=archived`
|
||||
- **THEN** the system SHALL return all archived rooms
|
||||
- **AND** include full room details
|
||||
|
||||
#### Scenario: Admin views all rooms including archived
|
||||
- **WHEN** a system administrator sends `GET /api/rooms` without status filter
|
||||
- **THEN** the system SHALL return all rooms regardless of status
|
||||
- **AND** include archived rooms in the response
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### 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.
|
||||
|
||||
#### 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
|
||||
- **AND** include room metadata (title, type, severity, member count, last activity)
|
||||
- **AND** sort by last_activity_at descending (most recent first)
|
||||
|
||||
#### Scenario: Non-admin user lists rooms without status filter
|
||||
- **WHEN** a non-admin user sends `GET /api/rooms` without status parameter
|
||||
- **THEN** the system SHALL return rooms with status "active" or "resolved" only
|
||||
- **AND** automatically exclude archived rooms from results
|
||||
@@ -0,0 +1,67 @@
|
||||
# frontend-core Specification Delta
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Incident Room List
|
||||
The frontend SHALL display a filterable, searchable list of incident rooms accessible to the current user. The frontend SHALL restrict the status filter options to show only "Active" and "Resolved" for non-admin users, and SHALL display all status options including "Archived" only for system administrators.
|
||||
|
||||
#### Scenario: Filter rooms by status (Non-admin)
|
||||
- **WHEN** a non-admin user views the status filter dropdown
|
||||
- **THEN** the system SHALL:
|
||||
- Display only "Active" and "Resolved" options
|
||||
- NOT display "Archived" option
|
||||
- NOT display "All Status" option that would include archived rooms
|
||||
|
||||
#### Scenario: Filter rooms by status (Admin)
|
||||
- **WHEN** a system administrator views the status filter dropdown
|
||||
- **THEN** the system SHALL:
|
||||
- Display all status options: "All Status", "Active", "Resolved", "Archived"
|
||||
- Allow viewing archived rooms
|
||||
|
||||
#### Scenario: Default status filter
|
||||
- **WHEN** a user navigates to the room list page
|
||||
- **THEN** the system SHALL:
|
||||
- Default to "Active" status filter for all users
|
||||
- Fetch only active rooms initially
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Admin Room Deletion Interface
|
||||
The frontend SHALL provide system administrators with the ability to permanently delete rooms through a dedicated UI control.
|
||||
|
||||
#### Scenario: Display delete button for admin
|
||||
- **WHEN** a system administrator views a room detail page
|
||||
- **THEN** the system SHALL:
|
||||
- Display a "Delete Room Permanently" button in room settings/actions
|
||||
- Style the button with warning color (red)
|
||||
- Only show this button to admin users
|
||||
|
||||
#### Scenario: Hide delete button for non-admin
|
||||
- **WHEN** a non-admin user views a room detail page
|
||||
- **THEN** the system SHALL:
|
||||
- NOT display permanent delete option
|
||||
- Only show standard archive option (if owner)
|
||||
|
||||
#### Scenario: Confirm permanent deletion
|
||||
- **WHEN** an admin clicks "Delete Room Permanently"
|
||||
- **THEN** the system SHALL:
|
||||
- Display a confirmation dialog with warning text
|
||||
- Require typing room name to confirm (optional safety measure)
|
||||
- Explain that deletion is irreversible
|
||||
- Show what will be deleted (messages, files, reports)
|
||||
|
||||
#### Scenario: Execute permanent deletion
|
||||
- **WHEN** an admin confirms permanent deletion
|
||||
- **THEN** the system SHALL:
|
||||
- Send DELETE request to `/api/rooms/{room_id}/permanent`
|
||||
- Show loading state during deletion
|
||||
- Navigate to room list on success
|
||||
- Show success toast message
|
||||
- Show error message on failure
|
||||
|
||||
#### Scenario: Handle active users in deleted room
|
||||
- **WHEN** a room is permanently deleted while other users are viewing it
|
||||
- **THEN** the system SHALL:
|
||||
- Receive WebSocket disconnect event
|
||||
- Display "Room has been deleted" message
|
||||
- Navigate affected users to room list
|
||||
@@ -0,0 +1,89 @@
|
||||
# Tasks: Add Admin Room Management
|
||||
|
||||
## Phase 1: Backend - Hide Archived Rooms
|
||||
|
||||
### 1.1 Modify room listing to exclude archived for non-admin
|
||||
- [x] Update `room_service.list_user_rooms()` to filter out ARCHIVED status for non-admin
|
||||
- [x] Ensure admin users can still see all statuses
|
||||
- [x] Handle case where non-admin explicitly requests `status=archived` (return empty)
|
||||
- [x] Write unit tests for filtered listing behavior
|
||||
|
||||
### 1.2 Update room count queries
|
||||
- [x] Ensure total count excludes archived for non-admin
|
||||
- [x] Verify pagination works correctly with filtered results
|
||||
|
||||
## Phase 2: Backend - Permanent Deletion
|
||||
|
||||
### 2.1 Fix room_files foreign key constraint
|
||||
- [x] Add `ondelete="CASCADE"` to room_files.room_id foreign key
|
||||
- [x] Create database migration or rebuild schema
|
||||
|
||||
### 2.2 Create permanent delete service method
|
||||
- [x] Add `permanent_delete_room()` method to room_service
|
||||
- [x] Implement cascading delete for all related tables
|
||||
- [x] Add MinIO file cleanup logic
|
||||
- [x] Handle WebSocket broadcast for room deletion event
|
||||
|
||||
### 2.3 Create permanent delete endpoint
|
||||
- [x] Add `DELETE /api/rooms/{room_id}/permanent` endpoint
|
||||
- [x] Implement admin-only authorization check
|
||||
- [x] Return appropriate error responses (403 for non-admin, 404 for not found)
|
||||
- [x] Write integration tests
|
||||
|
||||
## Phase 3: Frontend - Status Filter Changes
|
||||
|
||||
### 3.1 Add admin detection to frontend
|
||||
- [x] Create utility to check if current user is admin
|
||||
- [x] Store admin status in auth store or derive from username
|
||||
|
||||
### 3.2 Update room list status filter
|
||||
- [x] Conditionally render filter options based on admin status
|
||||
- [x] Remove "All Status" and "Archived" for non-admin users
|
||||
- [x] Keep default filter as "Active"
|
||||
- [x] Test filter behavior for both user types
|
||||
|
||||
## Phase 4: Frontend - Permanent Delete UI
|
||||
|
||||
### 4.1 Add delete button to room detail
|
||||
- [x] Create "Delete Room Permanently" button (admin only)
|
||||
- [x] Style with warning/danger color scheme
|
||||
- [x] Position in room settings or header actions
|
||||
|
||||
### 4.2 Implement confirmation dialog
|
||||
- [x] Create confirmation modal with warning text
|
||||
- [x] List what will be deleted (members, messages, files, reports)
|
||||
- [x] Add optional room name confirmation input
|
||||
- [x] Implement cancel and confirm buttons
|
||||
|
||||
### 4.3 Handle deletion flow
|
||||
- [x] Call DELETE `/api/rooms/{room_id}/permanent` on confirm
|
||||
- [x] Show loading state during deletion
|
||||
- [x] Navigate to room list on success
|
||||
- [x] Display error toast on failure
|
||||
|
||||
### 4.4 Handle WebSocket room deletion event
|
||||
- [x] Listen for room_deleted event in WebSocket handler
|
||||
- [x] Display notification to affected users
|
||||
- [x] Navigate users away from deleted room
|
||||
|
||||
## Phase 5: Testing & Validation
|
||||
|
||||
### 5.1 Backend tests
|
||||
- [x] Test non-admin cannot see archived rooms
|
||||
- [x] Test admin can see all rooms including archived
|
||||
- [x] Test permanent delete endpoint authorization
|
||||
- [x] Test cascading delete removes all related data
|
||||
- [x] Test MinIO cleanup on permanent delete
|
||||
|
||||
### 5.2 Frontend tests
|
||||
- [x] Test status filter options for admin vs non-admin
|
||||
- [x] Test delete button visibility
|
||||
- [x] Test confirmation dialog flow
|
||||
- [x] Test WebSocket room deletion handling
|
||||
|
||||
## Validation Checklist
|
||||
- [x] Run `openspec validate add-admin-room-management --strict`
|
||||
- [x] All existing tests pass
|
||||
- [x] New tests cover all scenarios
|
||||
- [x] Manual testing of full admin flow
|
||||
- [x] Manual testing of non-admin restrictions
|
||||
@@ -0,0 +1,64 @@
|
||||
# Proposal: Add Mobile Responsive Layout
|
||||
|
||||
## Summary
|
||||
Add device detection and responsive layout switching to optimize the user experience on mobile devices (<768px). The frontend currently only supports desktop and tablet layouts, leaving mobile users with horizontal scrolling issues and poor usability.
|
||||
|
||||
## Motivation
|
||||
- **Fixed sidebar widths** (w-72 for members, w-80 for files) cause horizontal overflow on mobile screens
|
||||
- **Header controls** don't adapt to narrow screens, causing button wrapping issues
|
||||
- **No mobile navigation pattern** - current horizontal nav doesn't collapse
|
||||
- **Small touch targets** - buttons use px-3 py-1.5 which is difficult to tap on mobile
|
||||
- Mobile devices are commonly used on the production floor for quick incident reporting
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
1. **Device Detection Hook** (`useIsMobile`) - Detect mobile vs desktop using media queries
|
||||
2. **Collapsible Sidebars** - Transform fixed sidebars into slide-in panels on mobile
|
||||
3. **Mobile Header** - Simplified header with hamburger menu or action sheet
|
||||
4. **Bottom Toolbar** - Move frequently used actions to bottom of screen for thumb-friendly access
|
||||
5. **Touch-Friendly Sizing** - Increase button/input sizes on mobile
|
||||
6. **Responsive Text** - Adjust font sizes for readability on small screens
|
||||
|
||||
### Out of Scope
|
||||
- Native mobile app (PWA can be considered later)
|
||||
- Offline functionality
|
||||
- Push notifications
|
||||
- Complex gestures (swipe to delete, etc.)
|
||||
|
||||
## Technical Approach
|
||||
|
||||
### Device Detection
|
||||
```typescript
|
||||
// hooks/useMediaQuery.ts
|
||||
export function useIsMobile(): boolean {
|
||||
return useMediaQuery('(max-width: 767px)')
|
||||
}
|
||||
|
||||
export function useIsTablet(): boolean {
|
||||
return useMediaQuery('(min-width: 768px) and (max-width: 1023px)')
|
||||
}
|
||||
```
|
||||
|
||||
### Layout Strategy
|
||||
- **Mobile (<768px)**: Single-column layout, slide-in sidebars, bottom action bar
|
||||
- **Tablet (768-1023px)**: Current behavior with minor adjustments
|
||||
- **Desktop (>1024px)**: Current behavior (unchanged)
|
||||
|
||||
### Key Component Changes
|
||||
|
||||
| Component | Mobile Behavior |
|
||||
|-----------|----------------|
|
||||
| RoomDetail Header | Collapse to hamburger menu, show essential actions only |
|
||||
| Members Sidebar | Slide-in from right, full-screen overlay |
|
||||
| Files Sidebar | Slide-in from right, full-screen overlay |
|
||||
| Message Input | Sticky bottom with larger touch targets |
|
||||
| Room Cards | Full-width single column |
|
||||
|
||||
## Impact
|
||||
- **frontend-core** spec: Add mobile-specific requirements to "Responsive Layout and Navigation"
|
||||
- Estimated file changes: ~8 frontend files
|
||||
- No backend changes required
|
||||
|
||||
## Related Changes
|
||||
- None (standalone improvement)
|
||||
@@ -0,0 +1,132 @@
|
||||
# mobile-layout Specification
|
||||
|
||||
## Purpose
|
||||
Provide responsive layout capabilities that detect user devices and adapt the UI for optimal mobile experience. This extends the existing "Responsive Layout and Navigation" requirement in frontend-core to include mobile devices (<768px).
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Responsive Layout and Navigation
|
||||
The frontend SHALL provide a responsive layout that works on desktop, tablet, and **mobile** devices with intuitive navigation. The system SHALL detect the device type and switch layouts accordingly.
|
||||
|
||||
#### Scenario: Mobile layout (<768px)
|
||||
- **WHEN** viewed on mobile devices (<768px width)
|
||||
- **THEN** the system SHALL:
|
||||
- Display a simplified header with hamburger menu
|
||||
- Show sidebars as full-screen slide-in panels (not inline)
|
||||
- Display a bottom toolbar with frequently used actions
|
||||
- Use single-column layout for content
|
||||
- Ensure all touch targets are at least 44x44 pixels
|
||||
|
||||
#### Scenario: Tablet layout (768px-1024px)
|
||||
- **WHEN** viewed on tablet (768px-1024px)
|
||||
- **THEN** the system SHALL:
|
||||
- Collapse sidebars to icons or overlay panels
|
||||
- Use full width for content areas
|
||||
- Stack panels vertically when needed
|
||||
|
||||
#### Scenario: Desktop layout (>1024px)
|
||||
- **WHEN** viewed on desktop (>1024px)
|
||||
- **THEN** the system SHALL:
|
||||
- Display full navigation and sidebars inline
|
||||
- Show room list and detail side-by-side when applicable
|
||||
- Display member/file panels as sidebars
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Device Detection
|
||||
The frontend SHALL provide hooks for detecting device type based on viewport width.
|
||||
|
||||
#### Scenario: Detect mobile device
|
||||
- **WHEN** the viewport width is less than 768px
|
||||
- **THEN** `useIsMobile()` hook SHALL return `true`
|
||||
- **AND** the UI SHALL render mobile-optimized components
|
||||
|
||||
#### Scenario: Detect tablet device
|
||||
- **WHEN** the viewport width is between 768px and 1023px
|
||||
- **THEN** `useIsTablet()` hook SHALL return `true`
|
||||
|
||||
#### Scenario: Detect desktop device
|
||||
- **WHEN** the viewport width is 1024px or greater
|
||||
- **THEN** `useIsDesktop()` hook SHALL return `true`
|
||||
|
||||
#### Scenario: Handle viewport resize
|
||||
- **WHEN** the user resizes the browser window across breakpoints
|
||||
- **THEN** the hooks SHALL update their return values
|
||||
- **AND** the UI SHALL transition smoothly to the appropriate layout
|
||||
|
||||
### Requirement: Mobile Navigation
|
||||
The frontend SHALL provide mobile-optimized navigation patterns for small screens.
|
||||
|
||||
#### Scenario: Display mobile header
|
||||
- **WHEN** on mobile layout in room detail view
|
||||
- **THEN** the system SHALL:
|
||||
- Show room title (truncated if necessary)
|
||||
- Show connection status indicator
|
||||
- Show hamburger menu button
|
||||
- Hide secondary action buttons (move to menu)
|
||||
|
||||
#### Scenario: Open mobile action menu
|
||||
- **WHEN** user taps the hamburger menu on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Display an action drawer/sheet from bottom or side
|
||||
- Show all room actions: Generate Report, Change Status, etc.
|
||||
- Allow closing by tapping outside or swipe gesture
|
||||
|
||||
#### Scenario: Display bottom toolbar
|
||||
- **WHEN** on mobile layout in room detail view
|
||||
- **THEN** the system SHALL:
|
||||
- Show a fixed bottom toolbar above the message input
|
||||
- Include buttons for: Files, Members
|
||||
- Use icons with labels for clarity
|
||||
- Ensure toolbar doesn't overlap with device safe areas
|
||||
|
||||
### Requirement: Mobile Sidebars
|
||||
The frontend SHALL display sidebars as slide-in panels on mobile devices.
|
||||
|
||||
#### Scenario: Open members panel on mobile
|
||||
- **WHEN** user taps the Members button on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Slide in a full-screen panel from the right
|
||||
- Display dark overlay behind the panel
|
||||
- Show member list with larger touch targets
|
||||
- Include a close button at the top of the panel
|
||||
|
||||
#### Scenario: Close sidebar panel
|
||||
- **WHEN** user taps the close button or backdrop overlay
|
||||
- **THEN** the system SHALL:
|
||||
- Slide the panel out to the right
|
||||
- Remove the dark overlay
|
||||
- Return focus to the main content
|
||||
|
||||
#### Scenario: Open files panel on mobile
|
||||
- **WHEN** user taps the Files button on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Slide in a full-screen panel from the right
|
||||
- Display file list with larger thumbnails
|
||||
- Show upload area with larger drop zone
|
||||
- Include a close button at the top
|
||||
|
||||
### Requirement: Touch-Friendly Interactions
|
||||
The frontend SHALL ensure all interactive elements are usable on touch devices.
|
||||
|
||||
#### Scenario: Minimum touch target size
|
||||
- **WHEN** displaying buttons, links, or interactive elements on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Ensure minimum touch target of 44x44 pixels
|
||||
- Provide adequate spacing between touch targets
|
||||
- Use padding to expand touch areas without changing visual size
|
||||
|
||||
#### Scenario: Mobile message input
|
||||
- **WHEN** user focuses the message input on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Expand input area for easier typing
|
||||
- Keep send button easily accessible
|
||||
- Handle soft keyboard appearance gracefully
|
||||
- Not obscure the input behind the keyboard
|
||||
|
||||
#### Scenario: Mobile form inputs
|
||||
- **WHEN** displaying form inputs on mobile (login, add member, etc.)
|
||||
- **THEN** the system SHALL:
|
||||
- Use larger input fields (minimum height 44px)
|
||||
- Show appropriate mobile keyboard type (email, text, etc.)
|
||||
- Support autocomplete where appropriate
|
||||
@@ -0,0 +1,98 @@
|
||||
# Tasks: Add Mobile Responsive Layout
|
||||
|
||||
## Phase 1: Foundation - Device Detection
|
||||
|
||||
- [x] **T-1.1**: Create `useMediaQuery` hook for responsive breakpoint detection
|
||||
- Create `/frontend/src/hooks/useMediaQuery.ts`
|
||||
- Export `useMediaQuery`, `useIsMobile`, `useIsTablet`, `useIsDesktop`
|
||||
- Add unit tests for hook behavior
|
||||
|
||||
- [x] **T-1.2**: Add mobile viewport meta and CSS custom properties
|
||||
- Ensure viewport meta tag is properly configured
|
||||
- Add CSS custom properties for safe area insets (notch handling)
|
||||
|
||||
## Phase 2: Mobile Navigation & Header
|
||||
|
||||
- [x] **T-2.1**: Create `MobileHeader` component with hamburger menu
|
||||
- Show essential info: room title, status, connection indicator
|
||||
- Hamburger button triggers action drawer
|
||||
- Implement slide-in action drawer for secondary actions
|
||||
|
||||
- [x] **T-2.2**: Create `BottomToolbar` component for mobile
|
||||
- Show: Files toggle, Members toggle, Message input trigger
|
||||
- Fixed position at bottom, above keyboard when active
|
||||
- Touch-friendly button sizes (min 44x44px)
|
||||
|
||||
- [x] **T-2.3**: Update `RoomDetail` header to switch between desktop and mobile layouts
|
||||
- Use `useIsMobile()` to conditionally render
|
||||
- Desktop: Current header layout
|
||||
- Mobile: `MobileHeader` + `BottomToolbar`
|
||||
|
||||
## Phase 3: Collapsible Sidebars
|
||||
|
||||
- [x] **T-3.1**: Create `SlidePanel` component for mobile sidebars
|
||||
- Full-height slide-in from right
|
||||
- Dark overlay backdrop
|
||||
- Close on backdrop click or swipe
|
||||
- Smooth CSS transitions
|
||||
|
||||
- [x] **T-3.2**: Update Members sidebar to use `SlidePanel` on mobile
|
||||
- Wrap existing member list content
|
||||
- Add close button at top
|
||||
- Full-screen width on mobile
|
||||
|
||||
- [x] **T-3.3**: Update Files sidebar to use `SlidePanel` on mobile
|
||||
- Wrap existing file list and upload area
|
||||
- Larger upload drop zone on mobile
|
||||
- Full-screen width on mobile
|
||||
|
||||
## Phase 4: Room List Mobile Optimization
|
||||
|
||||
- [x] **T-4.1**: Update `RoomList` layout for mobile
|
||||
- Full-width room cards (remove grid on mobile)
|
||||
- Stack filter controls vertically
|
||||
- Increase touch targets on filter buttons
|
||||
|
||||
- [x] **T-4.2**: Add mobile-optimized room card design
|
||||
- Larger status/severity badges
|
||||
- More padding for touch targets
|
||||
- Truncate long descriptions
|
||||
|
||||
## Phase 5: Touch-Friendly Inputs
|
||||
|
||||
- [x] **T-5.1**: Update message input for mobile
|
||||
- Larger input field (min height 44px)
|
||||
- Larger send button
|
||||
- Handle keyboard appearance gracefully
|
||||
|
||||
- [x] **T-5.2**: Update button and input sizes globally on mobile
|
||||
- Minimum touch target 44x44px
|
||||
- Larger form inputs
|
||||
- Use Tailwind responsive variants (sm: prefixes)
|
||||
|
||||
## Phase 6: Testing & Validation
|
||||
|
||||
- [x] **T-6.1**: Add responsive tests for key components
|
||||
- Test `useMediaQuery` hook with different window sizes
|
||||
- Test component rendering at mobile breakpoint
|
||||
- Test sidebar open/close behavior
|
||||
|
||||
- [x] **T-6.2**: Manual testing on actual devices
|
||||
- Test on iPhone Safari
|
||||
- Test on Android Chrome
|
||||
- Test keyboard interactions
|
||||
- Test safe area handling (notch)
|
||||
|
||||
- [x] **T-6.3**: Run full test suite and fix any regressions
|
||||
- `npm run test:run`
|
||||
- `npm run build`
|
||||
- Fix any TypeScript or lint errors
|
||||
|
||||
## Dependencies
|
||||
- T-1.1 must complete before T-2.x and T-3.x
|
||||
- T-3.1 must complete before T-3.2 and T-3.3
|
||||
- T-6.x depends on all other tasks
|
||||
|
||||
## Parallelizable Work
|
||||
- T-2.x (Navigation) and T-3.x (Sidebars) can run in parallel after T-1.1
|
||||
- T-4.x (Room List) can run in parallel with T-2.x and T-3.x
|
||||
@@ -52,23 +52,18 @@ The system SHALL allow authenticated users to create a new incident room with me
|
||||
- **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.
|
||||
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.
|
||||
|
||||
#### 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
|
||||
- **THEN** the system SHALL return all active rooms
|
||||
- **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
|
||||
#### Scenario: Non-admin user lists rooms without status filter
|
||||
- **WHEN** a non-admin user sends `GET /api/rooms` without status parameter
|
||||
- **THEN** the system SHALL return rooms with status "active" or "resolved" only
|
||||
- **AND** automatically exclude archived rooms from results
|
||||
|
||||
### 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.
|
||||
@@ -218,3 +213,50 @@ The system SHALL support predefined room templates for common incident types to
|
||||
- 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.
|
||||
|
||||
#### Scenario: Admin permanently deletes a room
|
||||
- **WHEN** a system administrator sends `DELETE /api/rooms/{room_id}/permanent`
|
||||
- **THEN** the system SHALL verify the user is ymirliu@panjit.com.tw
|
||||
- **AND** hard delete the room record from incident_rooms table
|
||||
- **AND** cascade delete all room_members records
|
||||
- **AND** cascade delete all messages and related reactions/edit_history
|
||||
- **AND** cascade delete all room_files records
|
||||
- **AND** delete associated files from MinIO storage
|
||||
- **AND** cascade delete all generated_reports records
|
||||
- **AND** delete associated report files from MinIO storage
|
||||
- **AND** broadcast disconnect event to any active WebSocket connections in the room
|
||||
- **AND** return status 200 with `{"message": "Room permanently deleted"}`
|
||||
|
||||
#### Scenario: Non-admin attempts permanent deletion
|
||||
- **WHEN** a non-admin user sends `DELETE /api/rooms/{room_id}/permanent`
|
||||
- **THEN** the system SHALL return status 403 with "Only system administrators can permanently delete rooms"
|
||||
|
||||
#### Scenario: Permanent delete non-existent room
|
||||
- **WHEN** a system administrator sends `DELETE /api/rooms/{room_id}/permanent` for a non-existent room
|
||||
- **THEN** the system SHALL return status 404 with "Room not found"
|
||||
|
||||
### Requirement: Hide Archived Rooms from Non-Admin Users
|
||||
The system SHALL hide rooms with ARCHIVED status from non-admin users in all listing operations, ensuring historical/archived data is only visible to system administrators.
|
||||
|
||||
#### Scenario: Non-admin lists rooms with any filter
|
||||
- **WHEN** a non-admin user sends `GET /api/rooms` with any status filter (including no filter)
|
||||
- **THEN** the system SHALL exclude all rooms with status "archived" from the response
|
||||
- **AND** only return rooms with status "active" or "resolved"
|
||||
|
||||
#### Scenario: Non-admin explicitly requests archived rooms
|
||||
- **WHEN** a non-admin user sends `GET /api/rooms?status=archived`
|
||||
- **THEN** the system SHALL return an empty list
|
||||
- **AND** return total count of 0
|
||||
|
||||
#### Scenario: Admin can view archived rooms
|
||||
- **WHEN** a system administrator sends `GET /api/rooms?status=archived`
|
||||
- **THEN** the system SHALL return all archived rooms
|
||||
- **AND** include full room details
|
||||
|
||||
#### Scenario: Admin views all rooms including archived
|
||||
- **WHEN** a system administrator sends `GET /api/rooms` without status filter
|
||||
- **THEN** the system SHALL return all rooms regardless of status
|
||||
- **AND** include archived rooms in the response
|
||||
|
||||
|
||||
@@ -36,35 +36,26 @@ The frontend SHALL provide a login interface that authenticates users against th
|
||||
- Redirect to login page
|
||||
|
||||
### Requirement: Incident Room List
|
||||
The frontend SHALL display a filterable, searchable list of incident rooms accessible to the current user.
|
||||
The frontend SHALL display a filterable, searchable list of incident rooms accessible to the current user. The frontend SHALL restrict the status filter options to show only "Active" and "Resolved" for non-admin users, and SHALL display all status options including "Archived" only for system administrators.
|
||||
|
||||
#### Scenario: Display room list
|
||||
- **WHEN** a logged-in user navigates to the room list page
|
||||
#### Scenario: Filter rooms by status (Non-admin)
|
||||
- **WHEN** a non-admin user views the status filter dropdown
|
||||
- **THEN** the system SHALL:
|
||||
- Fetch rooms from `GET /api/rooms`
|
||||
- Display rooms as cards with title, status, severity, and timestamp
|
||||
- Show the user's role in each room
|
||||
- Order by last activity (most recent first)
|
||||
- Display only "Active" and "Resolved" options
|
||||
- NOT display "Archived" option
|
||||
- NOT display "All Status" option that would include archived rooms
|
||||
|
||||
#### Scenario: Filter rooms by status
|
||||
- **WHEN** a user selects a status filter (Active, Resolved, Archived)
|
||||
#### Scenario: Filter rooms by status (Admin)
|
||||
- **WHEN** a system administrator views the status filter dropdown
|
||||
- **THEN** the system SHALL:
|
||||
- Update the room list to show only rooms matching the filter
|
||||
- Preserve other active filters
|
||||
- Display all status options: "All Status", "Active", "Resolved", "Archived"
|
||||
- Allow viewing archived rooms
|
||||
|
||||
#### Scenario: Search rooms
|
||||
- **WHEN** a user enters text in the search box
|
||||
#### Scenario: Default status filter
|
||||
- **WHEN** a user navigates to the room list page
|
||||
- **THEN** the system SHALL:
|
||||
- Filter rooms by title and description containing the search text
|
||||
- Update results in real-time (debounced)
|
||||
|
||||
#### Scenario: Create new room
|
||||
- **WHEN** a user clicks "New Room" and fills the creation form
|
||||
- **THEN** the system SHALL:
|
||||
- Display template selection if templates exist
|
||||
- Submit room creation to `POST /api/rooms`
|
||||
- Navigate to the new room on success
|
||||
- Show error message on failure
|
||||
- Default to "Active" status filter for all users
|
||||
- Fetch only active rooms initially
|
||||
|
||||
### Requirement: Incident Room Detail View
|
||||
The frontend SHALL display complete incident room information including metadata, members, and provide management controls for authorized users.
|
||||
@@ -270,3 +261,43 @@ The frontend SHALL provide a responsive layout that works on desktop and tablet
|
||||
- Log error details for debugging
|
||||
- Not crash or show blank screen
|
||||
|
||||
### Requirement: Admin Room Deletion Interface
|
||||
The frontend SHALL provide system administrators with the ability to permanently delete rooms through a dedicated UI control.
|
||||
|
||||
#### Scenario: Display delete button for admin
|
||||
- **WHEN** a system administrator views a room detail page
|
||||
- **THEN** the system SHALL:
|
||||
- Display a "Delete Room Permanently" button in room settings/actions
|
||||
- Style the button with warning color (red)
|
||||
- Only show this button to admin users
|
||||
|
||||
#### Scenario: Hide delete button for non-admin
|
||||
- **WHEN** a non-admin user views a room detail page
|
||||
- **THEN** the system SHALL:
|
||||
- NOT display permanent delete option
|
||||
- Only show standard archive option (if owner)
|
||||
|
||||
#### Scenario: Confirm permanent deletion
|
||||
- **WHEN** an admin clicks "Delete Room Permanently"
|
||||
- **THEN** the system SHALL:
|
||||
- Display a confirmation dialog with warning text
|
||||
- Require typing room name to confirm (optional safety measure)
|
||||
- Explain that deletion is irreversible
|
||||
- Show what will be deleted (messages, files, reports)
|
||||
|
||||
#### Scenario: Execute permanent deletion
|
||||
- **WHEN** an admin confirms permanent deletion
|
||||
- **THEN** the system SHALL:
|
||||
- Send DELETE request to `/api/rooms/{room_id}/permanent`
|
||||
- Show loading state during deletion
|
||||
- Navigate to room list on success
|
||||
- Show success toast message
|
||||
- Show error message on failure
|
||||
|
||||
#### Scenario: Handle active users in deleted room
|
||||
- **WHEN** a room is permanently deleted while other users are viewing it
|
||||
- **THEN** the system SHALL:
|
||||
- Receive WebSocket disconnect event
|
||||
- Display "Room has been deleted" message
|
||||
- Navigate affected users to room list
|
||||
|
||||
|
||||
132
openspec/specs/mobile-layout/spec.md
Normal file
132
openspec/specs/mobile-layout/spec.md
Normal file
@@ -0,0 +1,132 @@
|
||||
# mobile-layout Specification
|
||||
|
||||
## Purpose
|
||||
Provide responsive layout capabilities that detect user devices and adapt the UI for optimal mobile experience. This extends the existing "Responsive Layout and Navigation" requirement in frontend-core to include mobile devices (<768px).
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### Requirement: Responsive Layout and Navigation
|
||||
The frontend SHALL provide a responsive layout that works on desktop, tablet, and **mobile** devices with intuitive navigation. The system SHALL detect the device type and switch layouts accordingly.
|
||||
|
||||
#### Scenario: Mobile layout (<768px)
|
||||
- **WHEN** viewed on mobile devices (<768px width)
|
||||
- **THEN** the system SHALL:
|
||||
- Display a simplified header with hamburger menu
|
||||
- Show sidebars as full-screen slide-in panels (not inline)
|
||||
- Display a bottom toolbar with frequently used actions
|
||||
- Use single-column layout for content
|
||||
- Ensure all touch targets are at least 44x44 pixels
|
||||
|
||||
#### Scenario: Tablet layout (768px-1024px)
|
||||
- **WHEN** viewed on tablet (768px-1024px)
|
||||
- **THEN** the system SHALL:
|
||||
- Collapse sidebars to icons or overlay panels
|
||||
- Use full width for content areas
|
||||
- Stack panels vertically when needed
|
||||
|
||||
#### Scenario: Desktop layout (>1024px)
|
||||
- **WHEN** viewed on desktop (>1024px)
|
||||
- **THEN** the system SHALL:
|
||||
- Display full navigation and sidebars inline
|
||||
- Show room list and detail side-by-side when applicable
|
||||
- Display member/file panels as sidebars
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Device Detection
|
||||
The frontend SHALL provide hooks for detecting device type based on viewport width.
|
||||
|
||||
#### Scenario: Detect mobile device
|
||||
- **WHEN** the viewport width is less than 768px
|
||||
- **THEN** `useIsMobile()` hook SHALL return `true`
|
||||
- **AND** the UI SHALL render mobile-optimized components
|
||||
|
||||
#### Scenario: Detect tablet device
|
||||
- **WHEN** the viewport width is between 768px and 1023px
|
||||
- **THEN** `useIsTablet()` hook SHALL return `true`
|
||||
|
||||
#### Scenario: Detect desktop device
|
||||
- **WHEN** the viewport width is 1024px or greater
|
||||
- **THEN** `useIsDesktop()` hook SHALL return `true`
|
||||
|
||||
#### Scenario: Handle viewport resize
|
||||
- **WHEN** the user resizes the browser window across breakpoints
|
||||
- **THEN** the hooks SHALL update their return values
|
||||
- **AND** the UI SHALL transition smoothly to the appropriate layout
|
||||
|
||||
### Requirement: Mobile Navigation
|
||||
The frontend SHALL provide mobile-optimized navigation patterns for small screens.
|
||||
|
||||
#### Scenario: Display mobile header
|
||||
- **WHEN** on mobile layout in room detail view
|
||||
- **THEN** the system SHALL:
|
||||
- Show room title (truncated if necessary)
|
||||
- Show connection status indicator
|
||||
- Show hamburger menu button
|
||||
- Hide secondary action buttons (move to menu)
|
||||
|
||||
#### Scenario: Open mobile action menu
|
||||
- **WHEN** user taps the hamburger menu on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Display an action drawer/sheet from bottom or side
|
||||
- Show all room actions: Generate Report, Change Status, etc.
|
||||
- Allow closing by tapping outside or swipe gesture
|
||||
|
||||
#### Scenario: Display bottom toolbar
|
||||
- **WHEN** on mobile layout in room detail view
|
||||
- **THEN** the system SHALL:
|
||||
- Show a fixed bottom toolbar above the message input
|
||||
- Include buttons for: Files, Members
|
||||
- Use icons with labels for clarity
|
||||
- Ensure toolbar doesn't overlap with device safe areas
|
||||
|
||||
### Requirement: Mobile Sidebars
|
||||
The frontend SHALL display sidebars as slide-in panels on mobile devices.
|
||||
|
||||
#### Scenario: Open members panel on mobile
|
||||
- **WHEN** user taps the Members button on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Slide in a full-screen panel from the right
|
||||
- Display dark overlay behind the panel
|
||||
- Show member list with larger touch targets
|
||||
- Include a close button at the top of the panel
|
||||
|
||||
#### Scenario: Close sidebar panel
|
||||
- **WHEN** user taps the close button or backdrop overlay
|
||||
- **THEN** the system SHALL:
|
||||
- Slide the panel out to the right
|
||||
- Remove the dark overlay
|
||||
- Return focus to the main content
|
||||
|
||||
#### Scenario: Open files panel on mobile
|
||||
- **WHEN** user taps the Files button on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Slide in a full-screen panel from the right
|
||||
- Display file list with larger thumbnails
|
||||
- Show upload area with larger drop zone
|
||||
- Include a close button at the top
|
||||
|
||||
### Requirement: Touch-Friendly Interactions
|
||||
The frontend SHALL ensure all interactive elements are usable on touch devices.
|
||||
|
||||
#### Scenario: Minimum touch target size
|
||||
- **WHEN** displaying buttons, links, or interactive elements on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Ensure minimum touch target of 44x44 pixels
|
||||
- Provide adequate spacing between touch targets
|
||||
- Use padding to expand touch areas without changing visual size
|
||||
|
||||
#### Scenario: Mobile message input
|
||||
- **WHEN** user focuses the message input on mobile
|
||||
- **THEN** the system SHALL:
|
||||
- Expand input area for easier typing
|
||||
- Keep send button easily accessible
|
||||
- Handle soft keyboard appearance gracefully
|
||||
- Not obscure the input behind the keyboard
|
||||
|
||||
#### Scenario: Mobile form inputs
|
||||
- **WHEN** displaying form inputs on mobile (login, add member, etc.)
|
||||
- **THEN** the system SHALL:
|
||||
- Use larger input fields (minimum height 44px)
|
||||
- Show appropriate mobile keyboard type (email, text, etc.)
|
||||
- Support autocomplete where appropriate
|
||||
Reference in New Issue
Block a user