Files
TimeTracker/docs/development/LOCAL_TESTING_WITH_SQLITE.md
Dries Peeters 29f7186ee8 docs: Reorganize documentation structure for better navigation
Complete reorganization of project documentation to improve discoverability,
navigation, and maintainability. All documentation has been restructured into
a clear, role-based hierarchy.

## Major Changes

### New Directory Structure
- Created `docs/api/` for API documentation
- Created `docs/admin/` with subdirectories:
  - `admin/configuration/` - Configuration guides
  - `admin/deployment/` - Deployment guides
  - `admin/security/` - Security documentation
  - `admin/monitoring/` - Monitoring and analytics
- Created `docs/development/` for developer documentation
- Created `docs/guides/` for user-facing guides
- Created `docs/reports/` for analysis reports and summaries
- Created `docs/changelog/` for detailed changelog entries (ready for future use)

### File Organization

#### Moved from Root Directory (40+ files)
- Implementation notes → `docs/implementation-notes/`
- Test reports → `docs/testing/`
- Analysis reports → `docs/reports/`
- User guides → `docs/guides/`

#### Reorganized within docs/
- API documentation → `docs/api/`
- Administrator documentation → `docs/admin/` (with subdirectories)
- Developer documentation → `docs/development/`
- Security documentation → `docs/admin/security/`
- Telemetry documentation → `docs/admin/monitoring/`

### Documentation Updates

#### docs/README.md
- Complete rewrite with improved navigation
- Added visual documentation map
- Organized by role (Users, Administrators, Developers)
- Better categorization and quick links
- Updated all internal links to new structure

#### README.md (root)
- Updated all documentation links to reflect new structure
- Fixed 8 broken links

#### app/templates/main/help.html
- Enhanced "Where can I get additional help?" section
- Added links to new documentation structure
- Added documentation index link
- Added admin documentation link for administrators
- Improved footer with organized documentation links
- Added "Complete Documentation" section with role-based links

### New Index Files
- Created README.md files for all new directories:
  - `docs/api/README.md`
  - `docs/guides/README.md`
  - `docs/reports/README.md`
  - `docs/development/README.md`
  - `docs/admin/README.md`

### Cleanup
- Removed empty `docs/security/` directory (moved to `admin/security/`)
- Removed empty `docs/telemetry/` directory (moved to `admin/monitoring/`)
- Root directory now only contains: README.md, CHANGELOG.md, LICENSE

## Results

**Before:**
- 45+ markdown files cluttering root directory
- Documentation scattered across root and docs/
- Difficult to find relevant documentation
- No clear organization structure

**After:**
- 3 files in root directory (README, CHANGELOG, LICENSE)
- Clear directory structure organized by purpose and audience
- Easy navigation with role-based organization
- All documentation properly categorized
- Improved discoverability

## Benefits

1. Better Organization - Documentation grouped by purpose and audience
2. Easier Navigation - Role-based sections (Users, Admins, Developers)
3. Improved Discoverability - Clear structure with README files in each directory
4. Cleaner Root - Only essential files at project root
5. Maintainability - Easier to add and organize new documentation

## Files Changed

- 40+ files moved from root to appropriate docs/ subdirectories
- 15+ files reorganized within docs/
- 3 major documentation files updated (docs/README.md, README.md, help.html)
- 5 new README index files created
- 2 empty directories removed

All internal links have been updated to reflect the new structure.
2025-12-14 07:56:07 +01:00

5.2 KiB

Local Testing with SQLite

This document explains how to run TimeTracker locally for testing using SQLite instead of PostgreSQL.

Overview

The local test environment uses:

  • SQLite database instead of PostgreSQL (no separate database container needed)
  • Development mode with debug logging enabled
  • Local data persistence through Docker volumes
  • Simplified setup for quick testing and development

Quick Start

Windows:

scripts\start-local-test.bat

Linux/macOS:

./scripts/start-local-test.sh

PowerShell:

.\scripts\start-local-test.ps1

Option 2: Manual Docker Compose

docker-compose -f docker-compose.local-test.yml up --build

Configuration

The local test environment uses these key settings:

  • Database: SQLite at /data/timetracker.db (persisted in Docker volume)
  • Port: 8080 (same as production)
  • Environment: Development mode with debug enabled
  • Security: Secure cookies disabled for local testing
  • Logs: Available in ./logs/ directory

Environment Variables

You can override default settings using environment variables:

# Timezone
export TZ=Europe/Brussels

# Currency
export CURRENCY=EUR

# Admin users (comma-separated)
export ADMIN_USERNAMES=admin,testuser

# Secret key (change for security)
export SECRET_KEY=your-local-test-secret-key

# Start with custom settings
docker-compose -f docker-compose.local-test.yml up --build

Data Persistence

  • SQLite database: Stored in Docker volume app_data_local_test
  • Uploads: Stored in /data/uploads (persisted in Docker volume)
  • Logs: Stored in ./logs/ directory (mounted from host)

Stopping the Environment

# Stop containers
docker-compose -f docker-compose.local-test.yml down

# Stop and remove volumes (WARNING: This will delete all data)
docker-compose -f docker-compose.local-test.yml down -v

Accessing the Application

Once started, the application will be available at:

Database Management

Viewing SQLite Database

You can access the SQLite database directly:

# Copy database from container to host
docker cp timetracker-app-local-test:/data/timetracker.db ./local-db.sqlite

# Use sqlite3 command line tool
sqlite3 local-db.sqlite

# Or use any SQLite browser tool

Resetting Database

To start with a fresh database:

# Stop and remove volumes
docker-compose -f docker-compose.local-test.yml down -v

# Start again
docker-compose -f docker-compose.local-test.yml up --build

Troubleshooting

Container Won't Start

  1. Check Docker is running:

    docker info
    
  2. Check port 8080 is available:

    netstat -an | grep 8080
    
  3. View container logs:

    docker-compose -f docker-compose.local-test.yml logs app
    

Database Issues

  1. Check database file exists:

    docker exec timetracker-app-local-test ls -la /data/
    
  2. Reset database:

    docker-compose -f docker-compose.local-test.yml down -v
    docker-compose -f docker-compose.local-test.yml up --build
    

Permission Issues

The local test setup includes a custom entrypoint that automatically handles permissions. If you still encounter issues:

# Check container logs for permission errors
docker-compose -f docker-compose.local-test.yml logs app

# If needed, fix permissions manually
docker exec timetracker-app-local-test chown -R timetracker:timetracker /data

Entrypoint Issues

If you encounter issues with the entrypoint script (like su-exec: not found), you can use the simplified entrypoint:

  1. Edit docker-compose.local-test.yml and change the entrypoint line:

    # Change this line:
    entrypoint: ["/app/docker/entrypoint-local-test.sh"]
    
    # To this:
    entrypoint: ["/app/docker/entrypoint-local-test-simple.sh"]
    
  2. Restart the container:

    docker-compose -f docker-compose.local-test.yml down
    docker-compose -f docker-compose.local-test.yml up --build
    

The simplified entrypoint runs everything as root, which avoids user switching issues but is less secure (fine for local testing).

Differences from Production

Feature Local Test Production
Database SQLite PostgreSQL
Debug Mode Enabled Disabled
Secure Cookies Disabled Enabled
Data Volume app_data_local_test app_data
Container Name timetracker-app-local-test timetracker-app

Development Tips

  1. Hot Reload: The development environment supports hot reloading for Python changes
  2. Logs: Check ./logs/timetracker.log for detailed application logs
  3. Database: Use SQLite browser tools for easier database inspection
  4. Testing: This environment is perfect for testing new features before production deployment

Security Note

⚠️ Important: This local test environment is configured for development only:

  • Secure cookies are disabled
  • Debug mode is enabled
  • Uses a default secret key

Never use these settings in production!