- Replace "comprehensive" and other marketing terms with plain language
- Shorten overly detailed HTTP request documentation
- Simplify import structure and data resolution sections
- Remove verbose environment variables explanations
- Cut scheduled workflows examples to essential information
- Make language more direct and honest about development status
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Replace JSONPath references with Handlebars syntax
- Add comprehensive template examples and type conversion docs
- Update CHANGELOG with v0.0.39 breaking changes and migration notes
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Introduce `WorkflowBuilder` for visual workflow configuration
- Add child components: `WorkflowToolbar`, `StepConfigurationForm`, and `StepNode`
- Implement `WorkflowBuilderField` for integration with PayloadCMS
- Provide dynamic step type handling and JSON-based configuration editing
- Enhance UI with drag-and-drop functionality and step dependencies management
- Delete `MIGRATION-v0.0.37.md` as it is no longer necessary
- Remove outdated files: `test-helpers.ts`, `test-setup.ts`, `test-trigger.ts`, and `vitest.config.ts`
- Streamline project by eliminating obsolete and unused test-related files and configurations
- Delete unused test files: `basic.test.ts`, `condition-fix.spec.ts`, `create-document-step.test.ts`, and `error-scenarios.spec.ts`
- Streamline codebase by eliminating redundant and outdated test cases
- Improve maintainability by keeping only relevant and up-to-date tests
- Delete `initCollectionHooks` implementation and its usage references
- Remove `MIGRATION-v0.0.24.md` and `NOT-IMPLEMENTING.md` as they are now obsolete
- Update related workflow executor logic and TypeScript definitions, ensuring compatibility
- Simplify error handling, input parsing, and logging within workflow execution
- Clean up and refactor redundant code to improve maintainability
- Remove executorRegistry singleton pattern
- Create WorkflowExecutor on-demand in each hook execution
- Replace all 'any' types with proper TypeScript types
- Use CollectionAfterChangeHook and PayloadRequest types
- Simplify code by removing unnecessary state management
Benefits:
- Simpler, more maintainable code
- No shared state to manage
- Each hook execution is independent
- Proper TypeScript typing throughout
- Remove cron-trigger.ts and cron-scheduler.ts files
- Clean up cron-related code from plugin index and workflow hooks
- Remove cron references from workflow executor types
- Add cron to NOT-IMPLEMENTING.md with webhook alternatives
- Update README with scheduled workflow documentation using external services
- Suggest GitHub Actions and Vercel Cron as reliable alternatives
Benefits of external scheduling:
- Better reliability and process isolation
- Easier debugging and monitoring
- Leverages existing cloud infrastructure
- Reduces plugin complexity and maintenance burden
- Convert webhook, global, and cron triggers to use TriggerConfig pattern like collectionTrigger
- Simplify trigger slug names (remove '-trigger' suffix)
- Update validation to use new slug names
- Add perfectionist/sort-exports rule disable
- Note: Workflow.ts integration still needs fixes for type compatibility
- Standardize virtual field creation using triggerField helper
- Simplify field definitions by removing repetitive virtual field boilerplate
- Use consistent naming pattern: '__trigger_' + fieldName instead of '__builtin_'
- Preserve existing field conditions while adding parameter storage logic
- Update all trigger field modules to use Field type consistently
- Create dedicated triggers directory for trigger field configurations
- Extract collection, webhook, global, and cron trigger fields into separate modules
- Improve code organization and maintainability
- Update Workflow.ts to use the new modular trigger imports
- Change default log level to 'warn' for production
- Add PAYLOAD_AUTOMATION_LOG_LEVEL environment variable
- Remove all verbose config-phase logs
- Add documentation for log level control
- Change trigger debugging from debug to info level for visibility
- Add trigger condition evaluation logging with doc status
- Reduce verbose plugin config logs that spam dev console
- Help customer diagnose trigger matching issues more effectively
- Show detailed matching criteria for each trigger
- Display typeMatch, collectionMatch, operationMatch for debugging
- Help identify why triggers are not matching
- Assists in troubleshooting workflow execution issues
- Add lazy initialization when executor is not ready during hook execution
- Handles development hot-reloading scenarios where module registry resets
- Prevents 'Workflow executor not yet initialized' warnings
- Creates workflow executor on-demand when hooks fire before onInit
- Improved error handling and tracking for initialization failures
Resolves: Workflow executor timing issues in development environments
- Multiple step types (create-document, read-document, etc.) were defining collectionSlug fields
- These created duplicate field names at the same level in the Workflow collection
- Fixed by prefixing step field names with step slug (__step_{stepSlug}_{fieldName})
- Added virtual field hooks to store/retrieve data using original field names
- Resolves DuplicateFieldName error preventing PayloadCMS initialization
Fixes: #duplicate-field-name-issue
Closes: User bug report for @xtr-dev/payload-automation@0.0.30
- Change component paths from relative to @xtr-dev/payload-automation/client#Component
- Use proper PayloadCMS plugin import syntax for components
- Regenerate import map with correct package-based imports
- Resolves 'Module not found' errors in dev project
- Fix TypeScript types in trigger-helpers with proper interfaces
- Remove all ESLint no-explicit-any warnings with better typing
- Fix component import paths from @/components/* to relative paths
- Regenerate import map with correct component references
- All compilation and linting errors resolved
- Replace multiple helper functions with single createTriggerField function
- createTriggerField takes a standard PayloadCMS field and adds virtual storage hooks
- Simplify trigger presets to use the new createTrigger helper
- Update exports to match new simplified API
- Cleaner, more maintainable code with less boilerplate
- Remove redundant field name prefixing in Workflow.ts
- Custom trigger fields from trigger-helpers already have unique names
- Simplify by passing through inputs without modification
- Fixes DuplicateFieldName error
- Prefix custom trigger field names with trigger slug to avoid conflicts
- Built-in fields use __builtin_ prefix
- Custom trigger fields use __<triggerSlug>_ prefix
- Prevents naming collisions between different trigger types
- Add createTrigger() and createAdvancedTrigger() helpers
- Add preset builders: webhookTrigger, cronTrigger, eventTrigger, etc.
- Implement virtual fields with JSON backing for trigger parameters
- Eliminate 90% of boilerplate when creating custom triggers
- Add /helpers export path for trigger builders
- Fix field name clashing between built-in and custom trigger parameters
- Add comprehensive examples and documentation
- Maintain backward compatibility with existing triggers
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
