Gabriel20xx/CollabTable
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: remove outdated documentation files for FILTER_FEATURE, SERVER_SETUP_IMPLEMENTATION, and UPDATES

Browse Source
This commit is contained in:
Gabriel20xx
2025-11-11 22:52:09 +01:00
parent c76d47f687
commit d5bdc3e75d
3 changed files with 0 additions and 573 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FILTER_FEATURE.md
-135
View File
@@ -1,135 +0,0 @@
# Logs Filter Feature
## Overview
Added comprehensive filtering capabilities to the Android app's logs screen, allowing users to filter logs by severity, time range, and tags.
## Features
### 1. **Filter Button**
- Located in the top app bar next to the clear button
- Shows a red badge indicator when filters are active
- Opens a bottom sheet with all filter options
### 2. **Filter Options**
#### **Severity Filtering**
Filter by log level:
- ✅ DEBUG
- ✅ INFO
- ✅ WARN
- ✅ ERROR
Users can select multiple severity levels or deselect to hide certain log types.
#### **Time Range Filtering**
Filter logs by recency:
- Last 10 seconds
- Last 30 seconds
- Last minute
- Last 5 minutes
- Last 15 minutes
- Last hour
- Last 24 hours
- All time (default)
#### **Tag Filtering**
- Dynamically shows all unique tags from current logs
- Multi-select checkboxes for each tag
- "Select All" and "Clear All" buttons for convenience
- Only shows logs from selected tags (empty = show all)
### 3. **Active Filter Chips**
- Horizontal scrollable row below the app bar
- Shows all currently active filters as chips
- Tap any chip to remove that filter
- "Clear All" chip to reset all filters at once
- Only visible when filters are active
### 4. **Log Counter**
- Top bar shows: "Logs (filtered count/total count)"
- Example: "Logs (15/234)" means 15 logs match current filters out of 234 total
### 5. **Smart Empty States**
- "No logs yet" - when no logs exist
- "No logs match filters" - when logs exist but none match filters
## Implementation Details
### New Components
**TimeRange enum**
```kotlin
enum class TimeRange(val label: String, val milliseconds: Long) {
LAST_10_SECONDS("Last 10 seconds", 10_000),
LAST_30_SECONDS("Last 30 seconds", 30_000),
// ... etc
}
```
**LogFilters data class**
```kotlin
data class LogFilters(
val severities: Set<LogLevel> = LogLevel.values().toSet(),
val timeRange: TimeRange = TimeRange.ALL_TIME,
val tags: Set<String> = emptySet(),
val searchText: String = ""
)
```
**FilterBottomSheet composable**
- Modal bottom sheet with scrollable content
- Checkboxes for severities and tags
- Radio buttons for time range selection
- Reset button to clear all filters
### Filter Logic
Filters are applied in real-time using `remember()` with dependencies:
```kotlin
val filteredLogs = remember(logs, filters) {
val now = System.currentTimeMillis()
val cutoffTime = now - filters.timeRange.milliseconds
logs.filter { log ->
log.level in filters.severities &&
log.timestamp >= cutoffTime &&
(filters.tags.isEmpty() || log.tag in filters.tags) &&
(filters.searchText.isEmpty() || /* search logic */)
}
}
```
### Auto-scroll Behavior
- Automatically scrolls to the latest log when new logs arrive
- Works with filtered logs, not just all logs
## User Experience
1. **Opening filters**: Tap filter icon in top bar
2. **Applying filters**: Check/uncheck options in bottom sheet
3. **Viewing active filters**: See chips below app bar
4. **Quick removal**: Tap any filter chip to remove it
5. **Reset all**: Tap "Clear All" chip or "Reset All Filters" button
6. **Dismissing sheet**: Tap outside or swipe down
## Benefits
- **Debugging**: Quickly isolate ERROR/WARN logs
- **Performance**: Focus on specific time windows
- **Organization**: Filter by component/tag
- **Visibility**: Clear indication of active filters
- **Efficiency**: Persistent filters across log updates
- **UX**: Smooth animations and Material Design 3
## Technical Notes
- Uses Jetpack Compose with Material3
- State management with `remember` and `mutableStateOf`
- Filter state persists during screen lifetime
- Efficient filtering with Kotlin collections
- Responsive to real-time log updates
## Files Modified
- `LogsScreen.kt`: Complete rewrite with filter UI and logic
- Build verified successfully on both Android and Server
SERVER_SETUP_IMPLEMENTATION.md
-137
View File
@@ -1,137 +0,0 @@
# Server Setup Feature - Implementation Summary
## Overview
Added a mandatory server setup screen on first app startup with endpoint validation to ensure users configure a valid server URL before using the app.
## Features Added
### 1. First-Run Server Setup Screen
- **File**: `ServerSetupScreen.kt`
- Mandatory setup screen shown on first app launch
- User-friendly interface with clear instructions
- Real-time validation feedback with visual indicators
- Cannot be skipped - must validate successfully to proceed
- Tips card with connection examples for emulator and physical devices
### 2. Server Endpoint Validation
- **File**: `ServerSetupViewModel.kt`
- Validates URL format (must start with http:// or https://)
- Tests server connectivity by calling the `/health` endpoint
- Shows specific error messages:
- Connection failures
- Timeout errors
- Invalid URL format
- Server error codes
- Loading states with progress indicators
- Success confirmation before proceeding
### 3. First-Run Detection
- **Updated**: `PreferencesManager.kt`
- Added `isFirstRun()` method to check if app has been configured
- Added `setIsFirstRun(Boolean)` method to mark setup as complete
- Persists across app restarts using SharedPreferences
### 4. Updated Navigation Flow
- **Updated**: `AppNavigation.kt`
- Dynamically determines start destination based on first-run status
- Shows `server_setup` screen on first run
- Shows `lists` screen on subsequent runs
- Prevents navigation back to setup after completion
## User Experience Flow
### First App Launch:
1. User opens app for the first time
2. Server Setup screen is displayed automatically
3. User enters server URL
4. App validates the endpoint:
- Shows loading indicator during validation
- Displays success checkmark if valid
- Shows error message if invalid
5. On successful validation:
- Server URL is saved
- First-run flag is set to false
- User is navigated to Lists screen
6. User can now use the app normally
### Subsequent Launches:
1. User opens app
2. App checks first-run status
3. Directly shows Lists screen (normal flow)
4. User can still change server URL via Settings
## Validation Process
The validation performs these checks:
1. **URL Format**: Ensures URL starts with http:// or https://
2. **Normalization**: Adds trailing slash if missing
3. **Health Check**: Calls `/health` endpoint (converted from `/api/` path)
4. **Timeout**: 10-second timeout for connection attempts
5. **Error Handling**: User-friendly error messages for common issues
## Error Messages
- "URL must start with http:// or https://"
- "Cannot connect to server. Check URL and network."
- "Connection timeout. Server might be offline."
- "Server returned error: [code]"
- "Invalid URL format"
- "Error: [specific error message]"
## Settings Integration
Users can still:
- Change server URL later via Settings screen
- Test new URLs at any time
- View connection tips in Settings
## Technical Details
### Dependencies Used:
- OkHttp for HTTP requests
- Kotlin Coroutines for async operations
- StateFlow for reactive state management
- SharedPreferences for persistence
### Network Configuration:
- Connection timeout: 10 seconds
- Read timeout: 10 seconds
- Validates against `/health` endpoint
- Supports both HTTP and HTTPS
## Testing Recommendations
1. **First Run Test**:
- Clear app data
- Launch app
- Verify server setup screen appears
2. **Validation Test**:
- Test with valid URL (should succeed)
- Test with invalid URL (should show error)
- Test with unreachable server (should show connection error)
- Test with malformed URL (should show format error)
3. **Subsequent Launch Test**:
- After successful setup, close and reopen app
- Verify Lists screen appears directly
4. **Settings Test**:
- Navigate to Settings
- Change server URL
- Verify changes persist
## Files Modified/Created
### New Files:
- `app/src/main/java/com/collabtable/app/ui/screens/ServerSetupScreen.kt`
- `app/src/main/java/com/collabtable/app/ui/screens/ServerSetupViewModel.kt`
### Modified Files:
- `app/src/main/java/com/collabtable/app/data/preferences/PreferencesManager.kt`
- `app/src/main/java/com/collabtable/app/ui/navigation/AppNavigation.kt`
## Build Status
✅ Build successful with all tests passing
✅ No compilation errors
✅ All dependencies resolved correctly
UPDATES.md
-301
View File
@@ -1,301 +0,0 @@
# CollabTable - Updates Summary
## Latest Changes (October 2025)
### Field Editing Feature
**Added ability to edit field types and options after creation**
#### Android Changes:
- **New `EditFieldDialog` composable** in `ListDetailScreen.kt`
- Allows changing field type (STRING, PRICE, DROPDOWN, URL, DATE, TIME, DATETIME)
- Modify dropdown options or currency symbols
- Similar UI to AddFieldDialog for consistency
- **FieldHeader enhancements**
- Added Edit icon button next to field name
- Click to open EditFieldDialog
- Long-press still deletes field
- **ViewModel update**
- New `updateField()` method in `ListDetailViewModel`
- Updates field type and options in database
- Properly maintains field state
**Use case:** Change a STRING field to a DROPDOWN, or update dropdown options without recreating the field.
---
### Password Authentication Feature
**Server-side password protection with Android client support**
#### Server Changes:
1. **Environment Configuration** (`.env.example`)
- Added `SERVER_PASSWORD` environment variable
- Set your secure password in `.env` file
2. **Authentication Middleware** (`src/middleware/auth.ts`)
- Validates password on all `/api/*` routes
- Uses Bearer token format: `Authorization: Bearer <password>`
- `/health` endpoint remains unauthenticated
- Returns 401 for missing or invalid passwords
3. **Server Integration** (`src/index.ts`)
- Auth middleware applied before route handlers
- All API calls now require valid password
- Health check accessible without auth
#### Android Changes:
1. **PreferencesManager updates**
- `getServerPassword()` and `setServerPassword()` methods
- Secure storage in SharedPreferences
- Password persists across app sessions
2. **ServerSetupScreen enhancements**
- New password input field with show/hide toggle
- Password required for setup completion
- Validates password during initial setup
- Tests authentication before saving
3. **ServerSetupViewModel**
- Updated `validateAndSaveServerUrl()` to accept password
- Two-step validation: health check + authenticated request
- Stores password only after successful authentication
- Clear error messages for auth failures
4. **ApiClient authentication**
- New auth interceptor adds `Authorization` header
- Automatically includes password in all API requests
- Retrieves password from PreferencesManager
- No code changes needed in individual API calls
#### Setup Instructions:
**Server:**
```bash
# Set password in .env file
echo "SERVER_PASSWORD=your_secure_password" >> .env
# Restart server
docker-compose restart
```
**Android:**
1. Open app (first time or after reset)
2. Enter server URL
3. Enter server password
4. Tap "Validate and Continue"
5. Password is validated and stored
**Security Notes:**
- Password stored in Android SharedPreferences (encrypted on modern devices)
- Password sent via HTTPS in production (use SSL certificates)
- Consider using more robust auth (OAuth, JWT) for production use
- Current implementation is simple password-based authentication
---
## Previous Changes
### Android App Enhancements
#### 1. Settings Screen Added
- **New Files:**
- `PreferencesManager.kt` - Manages persistent storage of settings
- `SettingsScreen.kt` - UI for configuring server URL
- `SettingsViewModel.kt` - Business logic for settings
- **Features:**
- Settings icon in the main Lists screen toolbar
- Configurable server URL with validation
- Helpful tips for emulator vs physical device URLs
- Persistent storage across app restarts
- Success notification when URL is updated
#### 2. API Client Updates
- `ApiClient.kt` now initializes with saved preferences
- Server URL can be changed at runtime
- Automatically loads saved URL on app start
#### 3. Navigation Updates
- Added settings route to navigation graph
- Settings accessible from Lists screen
### Server Migration to SQLite
#### 1. Database Change
- **Replaced:** MongoDB → SQLite with Sequelize ORM
- **Reason:** Simpler deployment, built-in persistence, no separate database container needed
#### 2. Updated Dependencies
- **Removed:** `mongoose`
- **Added:** `sequelize`, `sqlite3`
#### 3. New Database Configuration
- `database.ts` - Sequelize connection setup
- Database path configurable via `DB_PATH` environment variable
- Default location: `/data/collabtable.db`
#### 4. Model Updates
All models converted from Mongoose schemas to Sequelize models:
- `List.ts`
- `Field.ts`
- `Item.ts`
- `ItemValue.ts`
#### 5. Routes Updates
All route handlers updated to use Sequelize methods:
- `findAll()` instead of `find()`
- `upsert()` instead of `findOneAndUpdate()`
- Sequelize operators (`Op.gt`) instead of MongoDB operators (`$gt`)
### Docker Configuration
#### 1. Simplified Setup
- **Removed:** MongoDB container
- **Changed:** Single server container with SQLite
- **Result:** Faster startup, simpler architecture
#### 2. Persistent Storage
- Docker volume: `sqlite_data`
- Mounted at: `/data` in container
- **Persists across:**
- Container restarts
- Container recreation
- `docker-compose down/up` cycles
#### 3. Environment Variables
- `PORT` - Server port (default: 3000)
- `DB_PATH` - SQLite database path (default: /data/collabtable.db)
- `NODE_ENV` - Environment mode
## How to Use
### Start the Server
```bash
cd CollabTableServer
docker-compose up -d
```
### Configure Android App
1. Open app in Android Studio
2. Build and run on device/emulator
3. Tap Settings icon (⚙️) in top bar
4. Enter server URL:
- **Emulator:** `http://10.0.2.2:3000/api/`
- **Physical Device:** `http://YOUR_IP:3000/api/`
5. Tap "Save"
### Backup Database
```bash
# Backup
docker cp collabtable-server:/data/collabtable.db ./backup.db
# Restore
docker cp ./backup.db collabtable-server:/data/collabtable.db
docker-compose restart
```
## Benefits
### Android App
✅ No hardcoded server URLs
✅ Easy to switch between environments
✅ User-friendly configuration
✅ Clear instructions for different device types
### Server
✅ Simpler deployment (one container vs two)
✅ No database configuration needed
✅ Built-in data persistence
✅ Easy backups (single file)
✅ Lower resource usage
✅ Faster startup time
## Testing
### Test Server Persistence
```bash
# Start server
docker-compose up -d
# Use the app to create data
# ...
# Restart server
docker-compose restart
# Data should still be there!
# Even after complete teardown
docker-compose down
docker-compose up -d
# Data persists because of the volume!
```
### Test Settings
1. Open app
2. Go to Settings
3. Change server URL
4. Close app
5. Reopen app
6. Go to Settings - URL should be saved!
## Architecture Diagram
```
┌─────────────────────┐
│ Android App │
│ (Material 3 UI) │
│ │
│ ┌───────────────┐ │
│ │ Settings │ │
│ │ Screen │ │
│ └───────────────┘ │
│ ↓ │
│ ┌───────────────┐ │
│ │ Preferences │ │
│ │ Manager │ │
│ └───────────────┘ │
│ ↓ │
│ ┌───────────────┐ │
│ │ API Client │ │
│ └───────────────┘ │
└──────────┬──────────┘
│ HTTP/REST
↓
┌─────────────────────┐
│ Docker Container │
│ │
│ ┌───────────────┐ │
│ │ Express.js │ │
│ │ Server │ │
│ └───────┬───────┘ │
│ ↓ │
│ ┌───────────────┐ │
│ │ Sequelize │ │
│ │ ORM │ │
│ └───────┬───────┘ │
│ ↓ │
│ ┌───────────────┐ │
│ │ SQLite │ │
│ │ Database │ │
│ └───────────────┘ │
│ ↓ │
│ /data/collabtable.db
│ ↓ │
└──────────┬──────────┘
│
Docker Volume
(sqlite_data)
```
## Notes
- TypeScript compilation errors shown are expected until dependencies are installed
- Run `npm install` in the server directory before local development
- The Android app works offline-first and syncs when connected
- Server validates and sanitizes all incoming data
- Timestamps are used for conflict resolution (latest wins)