* Add per-account toggle to disable automatic transaction categorization
Adds an `enable_category_matcher` boolean (default: true) to accounts so
users can opt out of Plaid's automatic category suggestions on a per-account
basis. When disabled, newly synced transactions arrive uncategorized so
rules or manual assignment take precedence.
- New migration adds `enable_category_matcher` column (default true, null: false)
- `PlaidEntry::Processor#matched_category` gates the CategoryMatcher call on the account flag
- Toggle rendered in the account edit modal for linked accounts (saves via main form submit)
- `AccountableResource#account_params` permits the new field
- `AccountsController#toggle_category_matcher` action added for potential API use
- i18n strings added for label and hint text
- Unit test covers the disabled-matcher path
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* Only show category matcher toggle for Plaid-linked accounts
Only PlaidEntry::Processor honors enable_category_matcher, but the toggle
rendered for every linked account, silently doing nothing for other
providers. Adds Account::Linkable#supports_category_matcher? (covering both
the legacy plaid_account_id link and AccountProvider rows) and gates the
form toggle on it. The SimpleFIN TODO now also points at this helper so the
toggle appears once SimpleFIN matching lands.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Add controller tests for category matcher toggle persistence and rendering
Covers the two paths flagged in review as untested: the flag persisting
through the shared AccountableResource#update action via account_params
(both disable and re-enable), and the edit form rendering the toggle only
for accounts where supports_category_matcher? is true.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Signed-off-by: Mike Lloyd <49411532+mike-lloyd03@users.noreply.github.com>
Signed-off-by: Juan José Mata <juanjo.mata@gmail.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Juan José Mata <juanjo.mata@gmail.com>
* fix(accounts): honor stored return_to after subtype account creation
Closes#1766.
The savings-goals empty-state "Add an account" CTA passes ?return_to, which
StoreLocation captures into session[:return_to], but account-creation flows
didn't always consume it:
- AccountableResource#create honored a form-carried return_to but not the
session value, so if the param wasn't threaded through the multi-step
new-account flow the user still landed on the account page. Added a
session[:return_to] fallback (the form param still wins).
- PropertiesController is a 3-step wizard (create → balances → address) that
never threaded return_to as a form param, and its final redirect went
straight to account_path. It now honors session[:return_to] on completion.
Rails blocks external-host redirects, so return_to can't open-redirect.
valuations#create uses redirect_back_or_to (referer-based) — different flow,
left as-is.
Tests: depository create prefers the form return_to and falls back to the
session value; property wizard completion honors the stored return_to.
* fix(accounts): block open-redirect via return_to; consume session value
Two AI-review findings on #2109:
- Open-redirect (codex): the property wizard's turbo_stream completion uses
stream_redirect_to, which the client resolves with Turbo.visit — that
full-navigates cross-origin, bypassing Rails' redirect host-guard. A crafted
?return_to=https://evil could walk the user off-site. Filter return_to at the
StoreLocation choke point (store time) to internal absolute paths only, and
sanitize the separate form-param channel, so an unsafe value can't reach
redirect_to / stream_redirect_to.
- Stale session (coderabbit): session[:return_to] was read but never consumed.
Consume it with delete at redirect time so it can't leak into a later flow.
Adds guard tests (external return_to falls back to the account page).
* fix(security): guard safe_return_to against non-String return_to
A crafted `?return_to[]=foo` makes params[:return_to] an Array, and
Array#match? doesn't exist, so safe_return_to raised NoMethodError
before the open-redirect hardening could reject it. Add an
is_a?(String) check as the first gate. Other CodeRabbit/Codex
return_to findings on this PR were already addressed (consume-side
re-validation + session.delete).
