* Add transaction type condition filter for rules
Add ability to filter rules by transaction type (income, expense, transfer).
This allows users to create rules that differentiate between transactions
with the same name but different types.
- Add Rule::ConditionFilter::TransactionType with select dropdown
- Register in TransactionResource condition_filters
- Add tests for income, expense, and transfer filtering
Closes#373
* Address PR review feedback for transaction type filter
- Fix income filter to exclude transfers and investment_contribution
- Fix expense filter to include investment_contribution regardless of sign
- Add i18n for option and operator labels
- Add tests for edge cases (transfer inflows, investment contributions)
Logic now matches Transaction::Search#apply_type_filter for consistency.
* fix: Preserve transaction tags during rule application
When rules set tags, they now ADD to existing tags instead of replacing
them. This fixes issue #518 where tags were being removed during bank sync.
The root cause was that SetTransactionTags called enrich_attribute with
just the single tag from the rule, which replaced all existing tags.
Now it merges the new tag with existing tags using .uniq to prevent
duplicates.
This preserves:
- User-applied tags that shouldn't be overwritten by rules
- Tags from other rules when multiple rules match the same transaction
- Tags set during previous syncs
* fix: Add nil guard for tag in SetTransactionTags
Return early with 0 if the tag is not found, preventing NoMethodError
when find_by_id returns nil. This matches the pattern used in
SetTransactionMerchant.
---------
Co-authored-by: Claude <noreply@anthropic.com>
- Deleted the `InvestmentActivityDetector` and associated tests.
- Removed rake tasks for backfilling and clearing investment activity labels.
- Simplified transaction processing in `SimplefinEntry::Processor` by removing inferred activity label logic.
- Added new rule `SetInvestmentActivityLabel` for setting labels using rules.
- Updated `Rule::Registry::TransactionResource` to include the new rule executor.
* Add Recent Runs visibility for rule executions
Adds a comprehensive tracking system for rule execution history with the following features:
- Creates RuleRun model to track execution metadata:
* Date/time of execution
* Execution type (manual/scheduled)
* Success/failure status
* Rule reference
* Transaction counts (processed and modified)
* Error messages for failed runs
- Updates RuleJob to automatically record execution results:
* Captures transaction processing statistics
* Handles success/failure states
* Stores error details for debugging
- Adds "Recent Runs" section to rules index page:
* Paginated display (20 runs per page)
* Columnar layout similar to LLM usage page
* Visual status indicators (success/failed badges)
* Error tooltips for failed runs
* Responsive design with design system tokens
- Includes i18n translations for all user-facing strings
This provides users with visibility into rule execution history, making it easier to debug issues and monitor rule performance.
* Update schema.rb with rule_runs table definition
* Linter noise
* Separate transaction counts into Queued, Processed, and Modified
Previously, the code eagerly reported transactions as "processed" when they
were only queued for processing. This commit separates the counts into three
distinct metrics:
- Transactions Queued: Count of transactions matching the rule's filter
conditions before any processing begins
- Transactions Processed: Count of transactions that were actually processed
and modified by the rule actions
- Transactions Modified: Count of transactions that had their values changed
(currently same as Processed, but allows for future differentiation)
Changes:
- Add transactions_queued column to rule_runs table
- Update RuleJob to track all three counts separately
- Update action executors to return count of modified transactions
- Update Rule#apply to aggregate modification counts from actions
- Add transactions_queued label to locales
- Update Recent Runs view to display new column
- Add validation for transactions_queued in RuleRun model
The tracking now correctly reports:
1. How many transactions matched the filter (queued)
2. How many were actually modified (processed/modified)
3. Distinguishes between matching and modifying transactions
* Add Pending status to track async rule execution progress
Introduced a new "pending" status for rule runs to properly track async
AI operations. The system now:
- Tracks pending async jobs with a counter that decrements as jobs complete
- Updates transactions_modified incrementally as each job finishes
- Only counts transactions that were actually modified (not just queued)
- Displays pending status with yellow badge in the UI
- Automatically transitions from pending to success when all jobs complete
This provides better visibility into long-running AI categorization and
merchant detection operations, showing real-time progress as Sidekiq
processes the batches.
* Fix migration version to 7.2 as per project standards
* Consolidate rule_runs migrations into single migration file
Merged three separate migrations (create, add_transactions_queued,
add_pending_jobs_count) into a single CreateRuleRuns migration.
This provides better clarity and maintains a clean migration history.
Changes:
- Updated CreateRuleRuns migration to include all columns upfront
- Removed redundant add_column migrations
- Updated schema version to 2025_11_24_000000
* Linter and test fixes
* Space optimization
* LLM l10n is better than no l10n
* Fix implementation for tags/AI rules
* Fix tests
* Use batch_size
* Consider jobs "unknown" status sometimes
* Rabbit suggestion
* Rescue block for RuleRun.create!
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Add change name rule for transaction
* Use HTML template in the ERB, clone and inject those templates from the stimulus controller
* Put back the ai_enabled check
* Update docs
* Example of what no case statement would look like
* Remove action_type and needs_value now that controller is injecting templates/hiding action target
* add "to" to template, improve no-option selection, ensure text box is cleared
* Domain model sketch
* Scaffold out rules domain
* Migrations
* Remove existing data enrichment for clean slate
* Sketch out business logic and basic tests
* Simplify rule scope building and action executions
* Get generator working again
* Basic implementation + tests
* Remove manual merchant management (rules will replace)
* Revert "Remove manual merchant management (rules will replace)"
This reverts commit 83dcbd9ff0aa7bbee211796b71aa48b71df5e57e.
* Family and Provider merchants model
* Fix brakeman warnings
* Fix notification loader
* Update notification position
* Add Rule action and condition registries
* Rule form with compound conditions and tests
* Split out notification types, add CTA type
* Rules form builder and Stimulus controller
* Clean up rule registry domain
* Clean up rules stimulus controller
* CTA message for rule when user changes transaction category
* Fix tests
* Lint updates
* Centralize notifications in Notifiable concern
* Implement category rule prompts with auto backoff and option to disable
* Fix layout bug caused by merge conflict
* Initialize rule with correct action for category CTA
* Add rule deletions, get rules working
* Complete dynamic rule form, split Stimulus controllers by resource
* Fix failing tests
* Change test password to avoid chromium conflicts
* Update integration tests
* Centralize all test password references
* Add re-apply rule action
* Rule confirm modal
* Run migrations
* Trigger rule notification after inline category updates
* Clean up rule styles
* Basic attribute locking for rules
* Apply attribute locks on user edits
* Log data enrichments, only apply rules to unlocked attributes
* Fix merge errors
* Additional merge conflict fixes
* Form UI improvements, ignore attribute locks on manual rule application
* Batch AI auto-categorization of transactions
* Auto merchant detection, ai enrichment in batches
* Fix Plaid merchant assignments
* Plaid category matching
* Cleanup 1
* Test cleanup
* Remove stale route
* Fix desktop chat UI issues
* Fix mobile nav styling issues
