- Add buildBillingItemsFilter() to provide required itemDate filter
BillingItems API requires a filter parameter and returns 500 error without it
- Add validation for task project_id foreign key references
Tasks with invalid project_id now have the field nullified instead of failing
- Add getValidProjectIds() method to fetch valid project IDs from database
Fixes:
- Billing Items: 'Value cannot be null. Parameter name: filters' error
- Tasks: 'violates foreign key constraint tasks_project_id_fkey' error
Both entities should now sync successfully.
- Separate Sync Status and Sync History into tabs with icons
- Fix pagination in sync history by adding offset parameter
- Update getSyncHistory to support offset for proper pagination
- Update API endpoint to pass offset parameter
- Previous/Next buttons now work correctly to navigate pages
This improves UX by organizing the sync page into logical sections
and enables users to browse through historical sync records.
The previous fix created the picklist sync methods but forgot to add
routing in the syncEntity() method. This caused the sync service to
still call the generic entity sync path instead of the picklist methods.
Added routing for:
- EntityType.STATUSES -> syncStatuses()
- EntityType.WORK_TYPES -> syncWorkTypes()
This completes the fix for the 404 errors on these picklist entities.
Problem:
- syncStatuses() and syncWorkTypes() were trying to query /Statuses/query
and /WorkTypes/query endpoints which don't exist in Autotask API
- This caused 404 errors: 'File or directory not found'
- These are picklist values, not queryable entities
Solution:
- Changed syncStatuses() to use getPicklistValues('Tickets', 'status')
- Changed syncWorkTypes() to use getPicklistValues('TimeEntries', 'workType')
- Now follows same pattern as syncIssueTypes() and syncSubIssueTypes()
- Uses proper picklist API endpoint: /entity/entityInformation/fields
This fixes today's sync failures for statuses and work_types entities.
- Explain all 4 sync options (Full, Incremental, Chunked, Selected)
- Detail when to use each sync type with real-world examples
- Document date range selector and its impact on performance
- List all entities with their dependencies
- Provide best practices for daily, weekly, and monthly syncs
- Include troubleshooting guide for common sync issues
- Add quick reference table for common scenarios
- Explain sync results (added/updated/deleted counts)
- Document API limits and performance considerations
- Reference analysis script for investigating failures
This guide clarifies the sync interface to help users understand what each option does and how to use it effectively.
- Add admin dashboard with sync controls and data browser
- Implement RMM, Auvik, and Addigy organization mappings
- Add chunked ticket sync with progress tracking
- Implement entity sync service with rate limiting
- Add analytics engine and performance optimizer
- Create data browser for all PSA entities
- Add navigation components and UI improvements
- Implement background processing and sync services
- Add comprehensive documentation and migration scripts
- Update configuration items with multi-system support
- Enhance contact management and purchase history
- Add issue type assignment and LLM analyzer
- Improve error handling and logging utilities
- Remove woff2 font files and validator.ts from repository
- Add *.woff2, validator.ts, and routes.ts to .gitignore
- These are Next.js build artifacts that should be generated during build
- Renamed project from PSA-Utils to Pulse
- Moved all app files from autotask-app/ to root
- Updated package.json name to 'pulse'
- Updated Docker container names to pulse-app and pulse-redis
- Updated Docker network name to pulse-network
- Implemented complete Addigy API v2 client with authentication via x-api-key
- Added device and policy endpoints with automatic org ID resolution
- Created field mapping from snake_case to Title Case for UI compatibility
- Handles nested 'facts' response structure from Addigy devices API
- Added comprehensive API documentation in ADDIGY_API_GUIDE.md
- Multi-stage Dockerfile with optimized production build
- Custom ports: App on 3100, Redis on 6380 (avoids conflicts)
- Docker Compose orchestration with health checks
- Standalone Next.js output for smaller container images
- Non-root user execution for security
- Implemented Redis caching layer for API responses
- 5-minute TTL with graceful fallback if Redis unavailable
- Cache key structure: service:entity:filter1:filter2
- Applied to Addigy devices endpoint with cache hit/miss logging
- Fixed TypeScript strict mode errors for production builds
- Added null safety checks with optional chaining throughout API routes
- Wrapped useSearchParams in Suspense boundary for Next.js 15+ compatibility
- Fixed type assertions for dynamic API responses
- Corrected Set<string> type mismatches in device comparison logic
- Created DOCKER_README.md with complete deployment guide
- Updated ADDIGY_API_GUIDE.md with real-world API patterns
- Documented response structures, field mappings, and troubleshooting
- Next.js 16.0.0 with Turbopack
- Redis 7 with AOF persistence
- Podman/Docker compatible
- TypeScript strict mode compliant
