indigo/LinkDesk
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Init Repo

Browse Source
This commit is contained in:
indigo
2026-02-28 03:22:04 +08:00
commit de59b57ee7
883 changed files with 156857 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.kiro/specs/recovery-management-rename/design.md
+198
View File
@@ -0,0 +1,198 @@
# Recovery Management Rename - Design Document
## Overview
This design document outlines the approach for renaming "Deleted Items Management" to "Recovery Management" throughout the VFX Project Management System. The change focuses on updating user-facing text and labels while preserving all existing functionality, file names, and API endpoints to maintain backward compatibility and minimize code changes.
## Architecture
The rename operation will be implemented as a pure UI/UX change that affects only the presentation layer. The underlying architecture remains unchanged:
- **Frontend Components**: Update display text, labels, and messages in Vue components
- **Navigation System**: Modify sidebar navigation labels while preserving route paths
- **Page Titles**: Update browser tab titles and page headers
- **User Messages**: Revise loading states, empty states, and notification text
## Components and Interfaces
### Affected Components
1. **AppSidebar.vue**
- Update navigation item title from "Deleted Items" to "Recovery Management"
- Preserve existing URL path `/admin/deleted-items` for backward compatibility
2. **DeletedItemsManagementView.vue**
- Update page title from "Deleted Items Management" to "Recovery Management"
- Revise page description to use recovery-focused language
- Update loading messages, empty states, and filter labels
- Add permanent delete actions for individual items
- Add bulk permanent delete functionality
- Add confirmation dialogs for permanent deletion
- Maintain all existing functionality and component structure
3. **RecoveryManagementPanel.vue** (if exists)
- Apply consistent terminology updates
- Ensure alignment with main management view
### New Components
4. **PermanentDeleteConfirmDialog.vue**
- Confirmation dialog for permanent deletion operations
- Warning messages about irreversible data loss
- Support for both individual and bulk operations
### Backend Services
5. **Recovery Service Extensions**
- Add permanent delete methods for shots and assets
- Implement cascading deletion for related data
- Add file system cleanup for associated files
- Ensure transactional integrity during deletion
### Interface Preservation
All existing interfaces will be preserved:
- Component props and events remain unchanged
- Service method signatures stay the same
- API endpoints maintain existing paths
- Database queries and models are unaffected
## Data Models
### Existing Models (Preserved)
All existing models remain unchanged for backward compatibility:
- `DeletedShot` interface preserved
- `DeletedAsset` interface preserved
- `RecoveryInfo` interface preserved
- Database tables and columns unchanged
- API response formats maintained
### New Interfaces
**PermanentDeleteRequest**
```typescript
interface PermanentDeleteRequest {
itemType: 'shot' | 'asset'
itemIds: number[]
confirmationToken: string
}
```
**PermanentDeleteResult**
```typescript
interface PermanentDeleteResult {
successful_deletions: number
failed_deletions: number
deleted_items: Array<{
id: number
name: string
type: 'shot' | 'asset'
}>
errors: Array<{
id: number
error: string
}>
files_deleted: number
database_records_deleted: number
}
```
### Database Operations
Permanent deletion will involve cascading deletes across multiple tables:
- Primary item record (shots/assets)
- Related tasks and their submissions
- Attachments and associated files
- Notes and reviews
- Activity records
- File system cleanup
## Correctness Properties
*A property is a characteristic or behavior that should hold true across all valid executions of a system-essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
### Property Reflection
After reviewing the acceptance criteria, several properties can be consolidated:
- Multiple criteria test similar text display functionality (page titles, labels, messages)
- Navigation and routing properties can be combined into comprehensive tests
- Terminology consistency can be verified through systematic text validation
**Property 1: Navigation displays recovery terminology**
*For any* admin user viewing the navigation menu, the menu should display "Recovery Management" and not display "Deleted Items"
**Validates: Requirements 1.1**
**Property 2: Navigation functionality preserved**
*For any* valid navigation interaction, clicking the recovery management menu item should navigate to the correct interface and maintain existing route functionality
**Validates: Requirements 1.2, 1.3**
**Property 3: Page content uses recovery terminology**
*For any* text element on the recovery management page, the content should use recovery-focused language and not contain deletion-focused terms
**Validates: Requirements 1.4, 2.2, 2.5, 3.2, 3.3, 3.4, 3.5**
**Property 4: API endpoints remain functional**
*For any* existing API endpoint used by the recovery management system, the endpoint should continue to return expected responses with unchanged functionality
**Validates: Requirements 4.2, 4.3**
**Property 5: Permanent deletion removes all related data**
*For any* soft-deleted item that is permanently deleted, all associated database records and files should be completely removed from the system
**Validates: Requirements 6.4, 7.1, 7.2, 7.3, 7.4**
**Property 6: Permanent deletion is transactional**
*For any* permanent deletion operation, either all related data is successfully removed or the entire operation is rolled back with no partial deletions
**Validates: Requirements 8.1, 8.4**
**Property 7: Permanent delete actions are available**
*For any* soft-deleted item displayed in the recovery interface, permanent delete actions should be available both individually and for bulk operations
**Validates: Requirements 6.1, 6.2**
**Property 8: Permanent deletion requires confirmation**
*For any* permanent deletion operation, a confirmation dialog with data loss warnings should be displayed before proceeding
**Validates: Requirements 6.3**
**Property 9: Permanent deletion provides feedback**
*For any* completed permanent deletion operation, the system should display success messages and update the interface to reflect the changes
**Validates: Requirements 6.5, 8.3**
## Error Handling
Error handling remains unchanged from the existing implementation:
- **Network Errors**: Maintain existing error messages with updated terminology
- **Authentication Errors**: Preserve existing auth error handling
- **Permission Errors**: Keep existing permission validation
- **Data Loading Errors**: Update error messages to use recovery terminology
- **Recovery Operation Errors**: Maintain existing error handling with terminology updates
## Testing Strategy
### Unit Testing Approach
Unit tests will focus on:
- **Text Content Verification**: Test that components render correct terminology
- **Navigation Behavior**: Verify navigation items work correctly
- **Route Preservation**: Ensure existing routes continue to function
- **Component Props**: Verify component interfaces remain unchanged
### Property-Based Testing Approach
Property-based tests will use **Vitest** with **fast-check** for JavaScript/TypeScript property testing. Each property-based test will run a minimum of 100 iterations.
**Property Test Requirements**:
- Each property-based test must be tagged with a comment referencing the design document property
- Tag format: `**Feature: recovery-management-rename, Property {number}: {property_text}**`
- Tests will generate various UI states and verify terminology consistency
- Navigation tests will verify route functionality across different scenarios
**Dual Testing Approach**:
- **Unit tests** will verify specific examples of correct terminology display
- **Property tests** will verify universal properties hold across all UI states
- Together they provide comprehensive coverage: unit tests catch specific text issues, property tests verify systematic terminology consistency
### Test Configuration
- **Framework**: Vitest for unit and property-based testing
- **Property Testing Library**: fast-check for generating test scenarios
- **Minimum Iterations**: 100 iterations per property-based test
- **Coverage**: Focus on UI text content, navigation behavior, and API compatibility
.kiro/specs/recovery-management-rename/requirements.md
+109
View File
@@ -0,0 +1,109 @@
# Requirements Document
## Introduction
This specification defines the requirements for renaming the "Deleted Items Management" feature to "Recovery Management" throughout the VFX Project Management System. This change improves the user experience by using more positive, action-oriented terminology that focuses on recovery capabilities rather than deletion.
## Glossary
- **Recovery Management**: The administrative interface for viewing and recovering soft-deleted items (shots and assets)
- **Soft Deletion**: The process of marking items as deleted without permanently removing them from the database
- **Recovery Interface**: The user interface components that allow administrators to restore deleted items
- **Navigation Menu**: The sidebar navigation system that provides access to different application sections
- **Admin Panel**: The administrative section of the application restricted to admin users
## Requirements
### Requirement 1
**User Story:** As an administrator, I want the navigation menu to show "Recovery Management" instead of "Deleted Items" so that the interface uses more positive terminology.
#### Acceptance Criteria
1. WHEN an administrator views the admin navigation menu THEN the system SHALL display "Recovery Management" instead of "Deleted Items"
2. WHEN the navigation item is clicked THEN the system SHALL navigate to the recovery management interface
3. WHEN the URL is accessed directly THEN the system SHALL maintain the same route path for backward compatibility
4. WHEN the page loads THEN the system SHALL display the updated terminology consistently
### Requirement 2
**User Story:** As an administrator, I want the page title and headers to reflect "Recovery Management" terminology so that the interface is consistent and user-friendly.
#### Acceptance Criteria
1. WHEN the recovery management page loads THEN the system SHALL display "Recovery Management" as the main page title
2. WHEN viewing the page description THEN the system SHALL use recovery-focused language instead of deletion-focused language
3. WHEN loading states are shown THEN the system SHALL display "Loading recovery data..." instead of "Loading deleted items..."
4. WHEN no items are found THEN the system SHALL display "No items available for recovery" instead of "No deleted items found"
5. WHEN displaying summary statistics THEN the system SHALL use "Items Available for Recovery" terminology
### Requirement 3
**User Story:** As an administrator, I want all user interface text to use recovery-focused language so that the system feels more positive and action-oriented.
#### Acceptance Criteria
1. WHEN viewing filter labels THEN the system SHALL use "Recovery Filters" instead of "Deleted Items Filters"
2. WHEN displaying item counts THEN the system SHALL show "Items Available for Recovery" instead of "Deleted Items"
3. WHEN showing empty states THEN the system SHALL display recovery-focused messaging
4. WHEN displaying error messages THEN the system SHALL use recovery terminology in error descriptions
5. WHEN showing success messages THEN the system SHALL maintain recovery-focused language
### Requirement 4
**User Story:** As a developer, I want the component and file names to remain unchanged so that existing functionality and references are preserved.
#### Acceptance Criteria
1. WHEN reviewing the codebase THEN the system SHALL maintain existing file names and component names
2. WHEN accessing API endpoints THEN the system SHALL preserve existing endpoint paths and functionality
3. WHEN viewing route configurations THEN the system SHALL maintain existing route paths for backward compatibility
4. WHEN examining service methods THEN the system SHALL preserve existing method names and interfaces
5. WHEN checking database schemas THEN the system SHALL maintain existing table and column names
### Requirement 5
**User Story:** As a system administrator, I want the browser tab title to reflect the new terminology so that the interface is consistent across all touchpoints.
#### Acceptance Criteria
1. WHEN the recovery management page is active THEN the browser tab SHALL display "Recovery Management" in the title
2. WHEN bookmarking the page THEN the bookmark SHALL use the updated terminology
3. WHEN sharing the page URL THEN the page title SHALL reflect the recovery management terminology
4. WHEN the page is indexed by search engines THEN the title SHALL use the updated terminology
### Requirement 6
**User Story:** As an administrator, I want to permanently delete soft-deleted items from the database so that I can free up storage space and permanently remove unwanted data.
#### Acceptance Criteria
1. WHEN viewing soft-deleted items THEN the system SHALL provide a "Permanent Delete" action for each item
2. WHEN selecting multiple soft-deleted items THEN the system SHALL provide a bulk permanent delete option
3. WHEN initiating permanent deletion THEN the system SHALL show a confirmation dialog warning about data loss
4. WHEN confirming permanent deletion THEN the system SHALL remove the item and all related data from the database
5. WHEN permanent deletion completes THEN the system SHALL show a success message and remove the item from the recovery list
### Requirement 7
**User Story:** As an administrator, I want permanent deletion to remove all related data so that no orphaned records remain in the database.
#### Acceptance Criteria
1. WHEN permanently deleting a shot THEN the system SHALL remove all associated tasks, submissions, attachments, notes, and reviews
2. WHEN permanently deleting an asset THEN the system SHALL remove all associated tasks, submissions, attachments, notes, and reviews
3. WHEN permanently deleting items THEN the system SHALL remove all associated activity records
4. WHEN permanent deletion occurs THEN the system SHALL delete all associated files from the file system
5. WHEN permanent deletion completes THEN the system SHALL ensure no foreign key references remain
### Requirement 8
**User Story:** As an administrator, I want permanent deletion to be irreversible and secure so that sensitive data is properly removed.
#### Acceptance Criteria
1. WHEN permanent deletion is confirmed THEN the system SHALL immediately remove data from the database
2. WHEN files are permanently deleted THEN the system SHALL remove them from the file system
3. WHEN permanent deletion occurs THEN the system SHALL log the action for audit purposes
4. WHEN permanent deletion fails THEN the system SHALL rollback all changes and show an error message
5. WHEN permanent deletion completes THEN the system SHALL ensure the action cannot be undone
.kiro/specs/recovery-management-rename/tasks.md
+210
View File
@@ -0,0 +1,210 @@
# Implementation Plan
## Overview
This implementation plan covers renaming "Deleted Items Management" to "Recovery Management" and adding permanent delete functionality for soft-deleted items. The tasks are organized to first implement the terminology changes, then add the hard delete features.
## Tasks
- [x] 1. Update navigation and routing terminology
- Update AppSidebar navigation item from "Deleted Items" to "Recovery Management"
- Preserve existing route paths for backward compatibility
- Update browser tab titles and page metadata
- _Requirements: 1.1, 1.2, 1.3, 5.1, 5.2, 5.3_
- [ ]* 1.1 Write property test for navigation terminology
- **Property 1: Navigation displays recovery terminology**
- **Validates: Requirements 1.1**
- [x] 2. Update main recovery management page terminology
- Update page title from "Deleted Items Management" to "Recovery Management"
- Revise page description to use recovery-focused language
- Update loading messages, empty states, and filter labels
- Update all user-facing text to use recovery terminology
- _Requirements: 1.4, 2.1, 2.2, 2.3, 2.4, 2.5, 3.1, 3.2, 3.3, 3.4, 3.5_
- [ ]* 2.1 Write property test for page content terminology
- **Property 3: Page content uses recovery terminology**
- **Validates: Requirements 1.4, 2.2, 2.5, 3.2, 3.3, 3.4, 3.5**
- [x] 3. Verify existing functionality preservation
- Test that all existing API endpoints continue to work
- Verify navigation and routing functionality is preserved
- Ensure component interfaces remain unchanged
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5_
- [ ]* 3.1 Write property test for API endpoint preservation
- **Property 4: API endpoints remain functional**
- **Validates: Requirements 4.2, 4.3**
- [x] 4. Checkpoint - Verify terminology updates
- Ensure all tests pass, ask the user if questions arise.
- [x] 5. Design permanent delete confirmation dialog
- Create PermanentDeleteConfirmDialog component
- Implement warning messages about irreversible data loss
- Add support for both individual and bulk operations
- Include confirmation token generation for security
- _Requirements: 6.3, 8.1_
- [x] 6. Implement backend permanent delete service
- Add permanent delete methods to recovery service
- Implement cascading deletion for related data (tasks, submissions, attachments, notes, reviews)
- Add file system cleanup for associated files
- Ensure transactional integrity with rollback on failure
- Add audit logging for permanent deletion operations
- _Requirements: 6.4, 7.1, 7.2, 7.3, 7.4, 7.5, 8.1, 8.3, 8.4_
- [ ]* 6.1 Write property test for cascading deletion
- **Property 5: Permanent deletion removes all related data**
- **Validates: Requirements 6.4, 7.1, 7.2, 7.3, 7.4**
- [ ]* 6.2 Write property test for transactional deletion
- **Property 6: Permanent deletion is transactional**
- **Validates: Requirements 8.1, 8.4**
- [x] 7. Add permanent delete API endpoints
- Create DELETE endpoints for permanent shot deletion
- Create DELETE endpoints for permanent asset deletion
- Add bulk permanent delete endpoints
- Implement proper error handling and validation
- Add rate limiting for permanent delete operations
- _Requirements: 6.4, 8.1, 8.4_
- [x] 8. Update recovery management interface with permanent delete actions
- Add "Permanent Delete" buttons to individual item cards
- Add bulk permanent delete option when items are selected
- Integrate confirmation dialog into the workflow
- Update success/error messaging for permanent deletions
- Remove permanently deleted items from the recovery list
- _Requirements: 6.1, 6.2, 6.5_
- [ ]* 8.1 Write property test for permanent delete UI actions
- **Property 7: Permanent delete actions are available**
- **Validates: Requirements 6.1, 6.2**
- [ ]* 8.2 Write property test for confirmation workflow
- **Property 8: Permanent deletion requires confirmation**
- **Validates: Requirements 6.3**
- [ ]* 8.3 Write property test for deletion feedback
- **Property 9: Permanent deletion provides feedback**
- **Validates: Requirements 6.5, 8.3**
- [x] 9. Implement permanent delete confirmation workflow
- Wire up confirmation dialog to permanent delete actions
- Implement confirmation token validation
- Add loading states during permanent deletion
- Handle success and error responses appropriately
- Update UI state after successful permanent deletion
- _Requirements: 6.3, 6.5, 8.1, 8.4_
- [x] 10. Add bulk permanent delete functionality
- Implement bulk selection for permanent deletion
- Add bulk confirmation dialog with item summary
- Handle partial success/failure scenarios in bulk operations
- Provide detailed feedback on bulk operation results
- _Requirements: 6.2, 6.5_
- [ ] 11. Checkpoint - Verify permanent delete functionality
- Ensure all tests pass, ask the user if questions arise.
- [ ] 12. Update documentation and help text
- Add help text explaining permanent deletion consequences
- Update any existing documentation references
- Add tooltips and contextual help for permanent delete actions
- _Requirements: 6.3, 8.5_
- [ ]* 12.1 Write unit tests for permanent delete components
- Test confirmation dialog rendering and behavior
- Test permanent delete button states and interactions
- Test bulk selection and permanent delete workflows
- _Requirements: 6.1, 6.2, 6.3_
- [ ] 13. Final integration testing
- Test complete workflow from soft delete to permanent delete
- Verify file system cleanup works correctly
- Test error scenarios and rollback behavior
- Verify audit logging is working properly
- _Requirements: 7.4, 8.1, 8.3, 8.4_
- [ ] 14. Final checkpoint - Complete system verification
- Ensure all tests pass, ask the user if questions arise.