Файловое хранилище готово

This commit is contained in:
2026-01-26 11:08:18 +03:00
parent a542e7d2df
commit edf9286071
35 changed files with 377 additions and 497 deletions

View File

@@ -6,30 +6,30 @@
## User Experience (File Management)
- [ ] CHK001 Are loading states displayed while fetching the file list? [Completeness]
- [ ] CHK002 Is visual feedback provided immediately after file upload starts? [Clarity]
- [ ] CHK003 Are error messages user-friendly when upload fails (e.g., "File too large" vs "Error 413")? [Clarity]
- [ ] CHK004 Is a confirmation modal shown before permanently deleting a file? [Safety]
- [ ] CHK005 Does the UI clearly distinguish between "Backups" and "Repositories" tabs? [Clarity]
- [ ] CHK006 Is the file list sortable by Date and Name? [Usability]
- [ ] CHK007 Are file sizes formatted in human-readable units (KB, MB, GB)? [Usability]
- [ ] CHK008 Is the download action easily accessible for each file item? [Accessibility]
- [ ] CHK009 Does the upload component support drag-and-drop interactions? [Usability]
- [ ] CHK010 Is the "Upload" button disabled or hidden when no category is selected? [Consistency]
- [x] CHK001 Are loading states displayed while fetching the file list? [Completeness]
- [x] CHK002 Is visual feedback provided immediately after file upload starts? [Clarity]
- [x] CHK003 Are error messages user-friendly when upload fails (e.g., "File too large" vs "Error 413")? [Clarity]
- [x] CHK004 Is a confirmation modal shown before permanently deleting a file? [Safety]
- [x] CHK005 Does the UI clearly distinguish between "Backups" and "Repositories" tabs? [Clarity]
- [x] CHK006 Is the file list sortable by Date and Name? [Usability]
- [x] CHK007 Are file sizes formatted in human-readable units (KB, MB, GB)? [Usability]
- [x] CHK008 Is the download action easily accessible for each file item? [Accessibility]
- [x] CHK009 Does the upload component support drag-and-drop interactions? [Usability]
- [x] CHK010 Is the "Upload" button disabled or hidden when no category is selected? [Consistency]
## Configuration Flexibility
- [ ] CHK011 Can the storage root path be configured to any writable directory on the server? [Flexibility]
- [ ] CHK012 Does the system support defining custom directory structures using variables like `{environment}`? [Flexibility]
- [ ] CHK013 Does the system support defining custom filename patterns using variables like `{timestamp}`? [Flexibility]
- [x] CHK011 Can the storage root path be configured to any writable directory on the server? [Flexibility]
- [x] CHK012 Does the system support defining custom directory structures using variables like `{environment}`? [Flexibility]
- [x] CHK013 Does the system support defining custom filename patterns using variables like `{timestamp}`? [Flexibility]
- [ ] CHK014 Are the supported pattern variables (e.g., `{dashboard_name}`) clearly documented in the UI? [Clarity]
- [ ] CHK015 Can the configuration be updated without restarting the application? [Usability]
- [x] CHK015 Can the configuration be updated without restarting the application? [Usability]
- [ ] CHK016 Is the current resolved path shown as a preview when editing patterns? [Usability]
- [ ] CHK017 Does the system allow reverting configuration to default values? [Recovery]
## Edge Cases & Error Handling
- [ ] CHK018 Is the UI behavior defined for an empty file list (zero state)? [Coverage]
- [x] CHK018 Is the UI behavior defined for an empty file list (zero state)? [Coverage]
- [ ] CHK019 Is the behavior defined when the configured storage path becomes inaccessible? [Resilience]
- [ ] CHK020 Are long filenames handled gracefully in the UI (e.g., truncation with tooltip)? [Layout]
- [ ] CHK021 Is the behavior defined for uploading a file with a duplicate name? [Conflict Resolution]
- [x] CHK020 Are long filenames handled gracefully in the UI (e.g., truncation with tooltip)? [Layout]
- [x] CHK021 Is the behavior defined for uploading a file with a duplicate name? [Conflict Resolution]

View File

@@ -5,7 +5,7 @@
## Summary
This feature implements a managed file storage system for dashboard backups and exported repositories. It introduces a configurable storage root (defaulting to outside the workspace) and a Web UI to list, upload, download, and delete files. The system enforces a structured layout with `backups/` and `repositories/` subdirectories to keep artifacts organized, while allowing flexible configuration of directory structures and filename patterns.
This feature implements a managed file storage system for dashboard backups and exported repositories. It introduces a configurable storage root (defaulting to outside the workspace) and a Web UI to list, upload, download, and delete files. The system enforces a structured layout with `backups/` and `repositories/` subdirectories to keep artifacts organized. The UI supports hierarchical folder navigation (e.g., `backups/SS2/DashboardName`), allowing users to browse, download, and manage files within nested directories.
## Technical Context
@@ -88,7 +88,8 @@ frontend/
│ │ └── +page.svelte # Main storage UI
│ ├── components/
│ │ └── storage/
│ │ ├── FileList.svelte # Component for listing files
│ │ ├── FileList.svelte # Component for listing files and folders (explorer view)
│ │ ├── Breadcrumbs.svelte # Component for navigation
│ │ └── FileUpload.svelte # Component for uploading
│ └── services/
│ └── storageService.js # Frontend API client

View File

@@ -9,18 +9,19 @@
### User Story 1 - File Management Dashboard (Priority: P1)
Users need a visual interface to manage the artifacts generated by the system (dashboard backups, exported repositories) without needing direct server access. This ensures that non-technical users or users without SSH access can still retrieve or clean up data.
Users need a visual interface to manage the artifacts generated by the system (dashboard backups, exported repositories) without needing direct server access. Users must be able to navigate through the folder structure (e.g., `backups/SS2/Sales Dashboard`) to locate specific files.
**Why this priority**: Core functionality requested. Without the UI, the storage mechanism is opaque and hard to use.
**Independent Test**: Can be fully tested by opening the new "File Storage" page, uploading a test file, verifying it appears in the list with correct metadata, downloading it, and then deleting it.
**Independent Test**: Can be fully tested by opening the new "File Storage" page, navigating into a subdirectory, uploading a test file, verifying it appears in the list, downloading it, and then deleting it.
**Acceptance Scenarios**:
1. **Given** the File Storage page is open, **When** I view the list, **Then** I see all files in the configured storage directory with their names, sizes, and creation dates.
2. **Given** a file exists in the list, **When** I click "Download", **Then** the file is downloaded to my local machine.
3. **Given** a file exists in the list, **When** I click "Delete" and confirm, **Then** the file is removed from the list and the server filesystem.
4. **Given** I have a file locally, **When** I drag and drop it or use the "Upload" button, **Then** the file is uploaded to the server storage and appears in the list.
1. **Given** the File Storage page is open, **When** I view the list, **Then** I see the top-level folders (e.g., `backups`, `repositories`) or files.
2. **Given** I am viewing a folder, **When** I click a subfolder name, **Then** the view updates to show the contents of that subfolder.
3. **Given** I am in a subfolder, **When** I click "Download" on a file, **Then** the file is downloaded to my local machine.
4. **Given** a file exists in the list, **When** I click "Delete" and confirm, **Then** the file is removed from the list and the server filesystem.
5. **Given** I have a file locally, **When** I drag and drop it or use the "Upload" button, **Then** the file is uploaded to the current directory and appears in the list.
---
@@ -64,11 +65,13 @@ Administrators need to control where potentially large or sensitive files are st
- **FR-001**: System MUST allow configuring a local filesystem root path for storing artifacts.
- **FR-002**: The default storage path MUST be configured such that it does not interfere with the application's git repository (e.g., a directory outside the workspace or explicitly git-ignored).
- **FR-003**: System MUST enforce a directory structure within the storage root: `backups/` for dashboard backups and `repositories/` for exported repositories.
- **FR-004**: System MUST provide a Web UI to list files, organized by their type (Backup vs Repository).
- **FR-004**: System MUST provide a Web UI to list files and folders, organized by their type (Backup vs Repository).
- **FR-005**: System MUST display file metadata in the UI: Filename, Size, Creation Date.
- **FR-006**: System MUST allow users to download files from the storage directory via the Web UI.
- **FR-006**: System MUST allow users to download files from the storage directory (including subdirectories) via the Web UI.
- **FR-007**: System MUST allow users to delete files from the storage directory via the Web UI.
- **FR-008**: System MUST allow users to upload files to the storage directory via the Web UI, requiring them to select the target category (Backup or Repository).
- **FR-008**: System MUST allow users to upload files to the specific folder in the storage directory via the Web UI.
- **FR-013**: System MUST support navigating through the directory hierarchy within the allowed categories.
- **FR-014**: System MUST display breadcrumbs or similar navigation aid to show current path.
- **FR-009**: System MUST validate that the configured storage path is accessible and writable.
- **FR-010**: System MUST prevent access to files outside the configured storage directory (Path Traversal protection).
- **FR-011**: System MUST allow configuring the directory structure pattern for backups and repositories (e.g., `{environment}/{dashboard_name}/`).

View File

@@ -64,6 +64,17 @@
- [x] T035 Verify large file upload support (50MB+) in Nginx/FastAPI config if applicable
- [x] T036 Add confirmation modal for file deletion
## Phase 6: Folder Structure Support (Refactor)
*Goal: Enable hierarchical navigation, nested file management, and downloading.*
- [x] T037 Refactor `StoragePlugin.list_files` in `backend/src/plugins/storage/plugin.py` to accept `subpath` and return directories/files
- [x] T038 Refactor `StoragePlugin` methods (`save_file`, `delete_file`, `get_file_path`) to support nested paths
- [x] T039 Update backend endpoints in `backend/src/api/routes/storage.py` (`GET /files`, `POST /upload`, `DELETE /files`, `GET /download`) to accept `path` parameter
- [x] T040 Update `frontend/src/services/storageService.js` to pass `path` argument in all API calls
- [x] T041 Update `frontend/src/components/storage/FileList.svelte` to display folder icons, handle navigation events, and show breadcrumbs
- [x] T042 Update `frontend/src/components/storage/FileUpload.svelte` to upload to the currently active directory
- [x] T043 Update `frontend/src/routes/tools/storage/+page.svelte` to manage current path state and handle navigation logic
## Dependencies
1. **Phase 1 (Setup)**: No dependencies.
@@ -71,6 +82,7 @@
3. **Phase 3 (US1)**: Depends on Phase 2.
4. **Phase 4 (US2)**: Depends on Phase 2. Can run parallel to Phase 3.
5. **Phase 5 (Polish)**: Depends on Phase 3 and 4.
6. **Phase 6 (Refactor)**: Depends on Phase 3.
## Parallel Execution Examples