The Activity Logs and System Logs UI implements a comprehensive visual system to help users quickly understand and navigate operation logs. The system includes:
Consistent Color Coding: Operation-specific colors across toolbar buttons, dialog headers, and log entries
Visual Grouping: Alternating backgrounds for related log entries
Navigation Controls: Browse through logs without closing the modal
Phase Badges: Clear indication of operation stages
Category-Based Operation Filters: Upload/Download/AI Indexing/Copy-Move/Delete/Create-Modify/Sync/Backup filters that hide batch and control implementation details
Optimized Layout: Streamlined columns for better readability
Warning Diagnostics Normalization: Pathless rclone notices such as NOTICE: Failed to copy: internal error ... are rendered as provider reasons instead of being mis-labeled as fake filenames or timestamps
Jobs Queue Lifecycle Coverage: Backup and sync job creation/deletion plus AI indexing cancel, retry, single dismiss, and completed-job batch dismiss controls are written to both user activity logs and system audit logs so queue changes remain traceable after a job row is removed
AI Indexing Outcome Summaries: AI indexing log rows and detail dialogs show eligible-file coverage, eligible failures/skips, and unsupported-by-policy counts separately instead of treating unsupported formats as operational failures
Color Coding System
Purpose
Provide visual consistency across the entire application using operation-specific colors for:
Enhanced the log details modal to display phase information prominently when the operation status is "pending".
Date: October 2025
Problem Statement
Previously, when a log entry had status "pending" and a phase ("start", "progress", "complete", "error"), the modal only displayed the status badge. The phase information was buried in the details grid below.
Solution
Display the status badge ("pending") alongside a separate phase badge ("start", "progress", etc.).
Benefits:
Clear separation of concerns
Easy to scan
Follows existing pattern (Operation + Status badges)
src/components/ContentToolbar.tsx - Applied color scheme
src/components/SearchActionToolbar.tsx - Applied color scheme
Testing
✅ Visual regression testing with Storybook
✅ Accessibility testing (WCAG compliance)
✅ Dark mode compatibility
✅ Keyboard navigation testing
✅ Responsive design testing
Activity Logs Partial Search Testing
Overview
The activity logs search functionality supports partial matching (substring search) for both operationId and requestId fields. This allows users to search using any portion of these long UUID identifiers.
Features
1. Partial Matching
Users can type just a portion of an operationId or requestId
Search works with the beginning, middle, or end of the ID string
Uses SQL ILIKE for case-insensitive pattern matching
2. Case-Insensitive Search
Search is case-insensitive for better usability
"6B24AA81" will match "6b24aa81-0de9-4235-8923-8ceaf751f819"
3. Special Character Escaping
SQL LIKE wildcards (%, _) are properly escaped
Prevents SQL injection and unexpected behavior
4. OR Logic Maintained
Search queries both operationId and requestId fields
Returns results that match either field
Manual Testing Steps
Test 1: Partial Match at Beginning
Navigate to /user/activity
In the search field, type: 6b24aa81
Expected: Should find logs with operationId starting with "6b24aa81-..."
Verify: Results are filtered correctly
Test 2: Partial Match in Middle
Clear the search field
Type: 8923-8ceaf751
Expected: Should find logs containing this substring in operationId or requestId
Verify: Results include logs with IDs containing this pattern
Test 3: Partial Match at End
Clear the search field
Type: f819 (last part of an ID)
Expected: Should find logs with IDs ending in "f819"
Verify: Results are filtered correctly
Test 4: Case-Insensitive Search
Clear the search field
Type: 6B24AA81 (uppercase)
Expected: Should find the same results as lowercase "6b24aa81"
Verify: Case doesn't affect search results
Test 5: Request ID Search
Clear the search field
Type a partial requestId (e.g., 8bb891c1)
Expected: Should find all logs with that requestId
Verify: Multiple related logs are returned (start, progress, complete phases)
Test 6: Very Short Search
Clear the search field
Type: 6b2 (very short partial)
Expected: Should find all logs containing "6b2" in operationId or requestId
Verify: Results may include multiple different operations
Test 7: No Results
Clear the search field
Type: xyz123nonexistent
Expected: Should show "No activity logs found yet."
Verify: Empty state is displayed correctly
Test 8: Clear Search
After any search, clear the search field completely
Expected: All logs should be displayed again
Verify: Full list is restored
Test 9: Special Characters (Edge Case)
Clear the search field
Type: test%search (contains SQL wildcard)
Expected: Should search for literal "test%search", not use % as wildcard
Verify: No SQL errors, proper escaping
Example Test Data
Suggested Partial Searches:
6b24aa81 - Beginning of operation ID
8923-8ceaf751 - Middle portion of operation ID
f819 - End of operation ID
8bb891c1 - Beginning of request ID
25c1-498f - Middle portion of request ID
1a3 - End of request ID
Expected Behavior
Successful Search:
Results appear immediately as you type
Matching IDs are highlighted in the results
Both operationId and requestId columns are searched
Case doesn't matter
No Results:
"No activity logs found yet." message is displayed
No errors in console
Search field remains functional
Edge Cases:
Very short searches (1-2 characters) may return many results
Special characters are treated as literals, not wildcards