1077 Commits

Include renames

Author	SHA1	Message	Date
Sure Admin (bot)	75aa16e4e2	Log async rule run failures to debug log (#3045) ... * Log async rule run failures to debug log * Propagate auto-categorize provider failures	2026-08-16 00:36:43 +02:00
Andrew B	c9fbfd9f71	fix(chat): make the assistant response timeout configurable (#2910) ... * fix(chat): make the assistant response timeout configurable (#2893) Self-hosted users running a local model report the chat failing with "assistant not available" after 90 seconds even though the model generates a reply and tokens are billed. Three timeouts are involved and only one was configurable: - OPENAI_REQUEST_TIMEOUT (60s) — already settable, not the blocker. - The browser watchdog in chat_controller.js (90s) — hardcoded, and this is what actually fires. - Chat::UNDELIVERED_RESPONSE_TIMEOUT (60s) — a constant, so raising the client value alone would not have helped. The watchdog cannot be avoided by streaming here: custom OpenAI-compatible providers route through generic_chat_response, which forces synchronous calls, so nothing renders until the whole generation finishes. Time-to-last-token has to beat the deadline. Adds AI_RESPONSE_TIMEOUT (ENV > Setting > 90s default, floored at 30s), exposed on the Self-Hosting settings page and passed to the Stimulus controller at all three mount points — show, index and the sidebar in the application layout, each of which declares data-controller="chat" independently. The server floor is derived from the same value but kept 10s below it. report_timeout answers 200 whether or not it acted and the client only retries on a non-ok response, so a floor at or above the client value would let clock skew strand a pending bubble permanently. Also guards AssistantMessage#append_text!. The watchdog runs in the web process while the job holds its own copy of the message, so a job finishing after the bubble was destroyed or demoted would silently resurrect it alongside the error the user was already shown. * fix(chat): let the watchdog retry when report_timeout declines `report_timeout` answered 200 whether or not `handle_undelivered_response!` acted. The Stimulus watchdog only stops retrying a URL once it sees a 2xx, so a declined report was treated as final. That stranded the bubble whenever the client's clock ran more than SERVER_TIMEOUT_GRACE ahead of the server's: the watchdog posts at its own timeout, the server sees a message younger than its floor and no-ops, and nothing ever retries. The bubble spins forever with no error and no Retry. Answering 409 instead lets the next 5s tick try again, so any amount of skew costs retries rather than a stuck chat. The grace window stays as an optimisation to keep those retries rare, not as the correctness mechanism. * docs(chat): correct the AI_RESPONSE_TIMEOUT ordering guidance The docs, locale string and examples all said to keep OPENAI_REQUEST_TIMEOUT at or above AI_RESPONSE_TIMEOUT. That is backwards. The two limits span different things. OPENAI_REQUEST_TIMEOUT bounds each HTTP call to the model on its own; AI_RESPONSE_TIMEOUT covers the whole turn and its clock starts when the message is queued, so it also absorbs Sidekiq queue time and, for a tool-using turn, two model calls plus the tool run between them. Keeping the chat timeout the larger of the two means a slow model surfaces the specific HTTP timeout error rather than a generic "no response", and the job stops instead of running on after the chat has given up. The shipped 60/90 defaults already had this ordering; only the guidance was wrong. compose.example.ai.yml gets 300/660 so the Ollama example can actually complete a tool-using turn. * fix(chat): claim the pending bubble atomically before appending append_text! read the row's status and then saved, leaving a window in which the watchdog could demote the row to `failed` between the two. The late content would then land on a bubble the user had already been told failed, flipping it back to `complete`. Replaces the read with a conditional UPDATE that only succeeds while the row is still pending, so the check and the state change cannot be separated. Uses a conditional UPDATE rather than with_lock because append_text! is called once per chunk on the streaming path; a row lock and transaction per chunk would be far more expensive. The claim only runs on the first append, since later ones are no longer pending. * test(chat): isolate AI_RESPONSE_TIMEOUT from the environment Chat.response_timeout reads ENV ahead of Setting, so stubbing only the Setting left the assertions at the mercy of the environment they run in. With AI_RESPONSE_TIMEOUT=45 exported, five of these tests failed — the default, floor and grace assertions were all silently measuring the env value. Adds a with_setting_timeout helper that stubs the Setting and clears the variable together, and switches the controller tests to stub Chat.undelivered_response_timeout directly, since what they care about is the resolved floor rather than how it was configured. Both files now pass with or without AI_RESPONSE_TIMEOUT set. * docs(chat): size AI_RESPONSE_TIMEOUT for chained tool calls The guidance assumed a tool-using turn costs two model calls. #2767 landed after this branch was opened and made tool calls iterative: `Assistant::Responder` now loops until `iteration > max_tool_call_iterations`, so a turn runs to 1 + ASSISTANT_MAX_TOOL_CALL_ITERATIONS calls — six by default — with tool execution in between. At the default 60s per-call timeout that is up to 360s of model time against a 90s watchdog. Streaming does not rescue this either. `emit(:output_text)` only fires for a response that carries text, and tool-call-only rounds carry none, so the bubble stays on "Thinking…" through every round regardless of provider. Documents ASSISTANT_MAX_TOOL_CALL_ITERATIONS as the cheaper lever: dropping it to 2 halves the worst case instead of demanding a half-hour timeout, at the cost of failing long tool chains earlier with a clear limit error. compose.example.ai.yml now shows that combination rather than a timeout sized for six calls it never had. * docs(chat): state the whole-turn timeout as a sum, not a maximum The guidance said to keep AI_RESPONSE_TIMEOUT "above" or "the larger of" OPENAI_REQUEST_TIMEOUT. That understates it: the watchdog covers the entire turn, so the bound is (1 + ASSISTANT_MAX_TOOL_CALL_ITERATIONS) * OPENAI_REQUEST_TIMEOUT + tool execution + queue wait Merely exceeding the per-call limit can still leave the chat reporting failure while the worker keeps going. One phrasing was outright wrong: "keep AI_RESPONSE_TIMEOUT the largest of the three" compared a duration against ASSISTANT_MAX_TOOL_CALL_ITERATIONS, which is a count, not seconds. Resizes the examples against the formula — compose.example.ai.yml 1000 -> 1200 and the Ollama doc example 600 -> 720, both now showing the arithmetic — and states plainly that the 90s default is sized for typical cloud latency rather than the worst-case bound, with the formula being what matters once per-call latency approaches the timeout. * docs(chat): list the AI settings fields and tag the formula fence The Settings UI walkthrough listed three of the eight fields on the AI Provider form. JSON Mode, the three Token Budget fields and the new Chat Response Timeout were all missing, so the timeout was only discoverable from the troubleshooting section. Rewrites the list to follow the form's own grouping and uses the labels the form actually renders. Also tags the whole-turn formula fence as `text` (markdownlint MD040). * fix(compose): forward ASSISTANT_MAX_TOOL_CALL_ITERATIONS in standard compose This file enumerates container environment explicitly — there is no env_file — so a variable absent from the x-rails-env anchor never reaches web or worker. The tool-call cap was only named in a comment here, while the docs added in 3360dbf5 tell operators to lower it to keep a turn inside AI_RESPONSE_TIMEOUT. Following that advice on this compose file silently changed nothing: the app kept the default of 5 while the timeout was sized for 3 calls, which lands back on the "no response" error this branch exists to fix. Left with an empty default so the app's own default governs, matching OPENAI_MODEL and LLM_CONTEXT_WINDOW above. compose.example.ai.yml already forwarded it.	2026-08-15 06:12:22 +02:00
Sure Admin (bot)	73d43bc1d0	Fix SSO JIT new family creator role (#3024) ... * Fix SSO JIT new family creator role * Preserve super admin SSO creator defaults * Update new family creator role test	2026-08-14 03:59:02 +02:00
Guillem Arias Fauste	7f0a6fb6dc	chore: drop dead transactions-section preferences (#3021) ... `transactions_section_controller.js` was added by #454 for the upcoming recurring-transactions section. #771 moved recurring transactions to a dedicated tab and removed the only mount, so the controller and its whole persistence chain have been dead since then: `data-controller="transactions-section"` appears nowhere in app/views or app/components, and `transactions_section_collapsed?` had no callers outside its own definition. Removed: - app/javascript/controllers/transactions_section_controller.js - User#update_transactions_preferences - User#transactions_section_collapsed? - TransactionsController#update_preferences + #preferences_params - the `patch :update_preferences` route on the transactions collection The only caller of /transactions/update_preferences was the dead controller itself. No tests referenced any of it — the `update_preferences` cases in pages_controller_test cover the dashboard's route — which is how it stayed dead unnoticed. No migration: users who collapsed a section before #771 keep a stale `transactions_collapsed_sections` key in `users.preferences`, and nothing reads it after this. The dashboard and reports section-layout preferences are untouched.	2026-08-14 03:52:13 +02:00
Brandon	1973c557e5	fix(ai): drop empty data-driven enums from assistant function schemas (#3016) ... * fix(ai): drop empty data-driven enums from assistant function schemas Enum values in tool schemas are built from family data (account names, categories, merchants, tags, tickers). A family with none of these gets enum: [], which is invalid JSON Schema. OpenAI tolerates it, but strict OpenAI-compatible providers reject the entire request, breaking chat for fresh families until they create a tag or merchant. Prune empty enums in build_schema, falling back to a plain string. One choke point covers every function and both consumers: chat tool definitions for all providers, and the /mcp endpoint's tools/list. * fix(ai): address review feedback on enum pruning Stop recursion at populated enum values: enum members are literal values, not subschemas, so a literal like enum: [{ enum: [] }] must be preserved verbatim rather than rewritten. Also cover PREVIEW_FUNCTION_CLASSES in the registry regression test by enabling the preview preference on the test user, with a guard assertion so the test fails if preview functions ever silently drop out.	2026-08-14 02:59:59 +02:00
GFRandClaude Sonnet 5	746d56c4bd	fix: gracefully handle invalid family timezone instead of crashing (#2821) ... * fix: gracefully handle invalid family timezone instead of crashing Family#timezone is a free-text IANA zone name with no validation on write. If it becomes stale (e.g. tzdata renames a zone, like the historical Europe/Kiev -> Europe/Kyiv switch) or a migration meant to remap legacy names never ran, Localize#switch_timezone passed the raw string straight to Time.use_zone, which raises ArgumentError for any unrecognized zone. Since switch_timezone runs as an around_action on every request, this crashed the entire app for the affected family, including the login page. Now validates the zone via ActiveSupport::TimeZone[] first and falls back to the app default (logging a DebugLogEntry) instead of raising. The log write is debounced per (family, bad value) via Rails.cache (once per day) so an affected family doesn't write one DebugLogEntry row per page view indefinitely. Fixes #390 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: address review feedback on timezone fallback - Make the invalid-timezone debounce lease atomic. Rails.cache.fetch is read-then-write, not atomic, so two concurrent requests could both observe a cache miss and both log before either write landed. Rails.cache.write(unless_exist: true) maps to Redis's atomic SET NX in production, so only one request ever wins the lease. (via CodeRabbit) - Stop using "Europe/Kiev" as the invalid-timezone value in tests. Whether ActiveSupport::TimeZone still resolves that legacy alias depends on the host's installed tzdata version (tzinfo-data is Windows/JRuby-only per Gemfile), so the test's pass/fail behavior wasn't deterministic across machines/CI. Use a deliberately nonexistent name instead. (via Codex) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: validate Family#timezone on write to address root cause of #390 The previous commit made the *crash* graceful, but left the actual defect in place: nothing stopped an unrecognized IANA zone name from being written to Family#timezone in the first place (direct DB/API access, an old dump predating a tzdata rename, or a future rename of a currently-valid zone). Add a Family-level validation using the same ActiveSupport::TimeZone[] lookup Localize#resolved_timezone uses at request time, so "valid at save" and "valid when rendering" can't drift apart. Deliberately not `inclusion: { in: ActiveSupport::TimeZone.all.map(&:name) }`, matching the neighboring locale/date_format validations: verified empirically that the settings form submits `tz.tzinfo.identifier` (e.g. "America/New_York"), not `tz.name` (e.g. "Eastern Time (US & Canada)"), and those differ for all 150 zones Rails ships. An inclusion check against `.name` would have rejected every legitimate value the form submits. The validation only runs when timezone is actually being changed (if: :timezone_changed?). A family with a pre-existing bad value (the exact #390 scenario) must still be able to save unrelated changes -- otherwise this would turn a previously-harmless bad value into a blocker for any other settings update or background job touching that family's record. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-14 02:58:40 +02:00
Guillem Arias Fauste	214a139a7e	fix(goals): stop the days-left phrase splitting across lines (#2970) ... * fix(goals): stop the days-left phrase splitting across lines The goal header read "Target 700 € by 08 de Febrer de 2027 · 184 days left" as one text node, so on a phone it wrapped wherever it ran out of room — "184 days" on the first line and "left" orphaned on the second. `header_summary_parts` now returns the dot-separated segments instead of a joined string, and the view renders each as its own span. Only the segments after the first are `whitespace-nowrap`: the first carries the target and a long-format date and has to stay free to wrap, or it would overflow a narrow screen. Checked at 320px, where the first segment takes two lines and "675 days left" still moves down whole. * test(goals): pin the clock for the days-left assertion The count is `target_date - Date.current`, and the target was set from `184.days.from_now` a moment earlier — a suite crossing midnight between the two would compute 183 and fail. Wrap it in travel_to, matching the idiom in budget_category_test and family_export_test. The neighbouring 'omits days left once reached' test asserts only the segment count, which 183 and 184 satisfy equally, so it is left alone.	2026-08-13 06:43:31 +02:00
Blaž Dular	37301e15ae	feat(mcp): add pagination to get_tags and get_categories tools (#2492) ... * feat(mcp): add pagination to get_tags and get_categories tools Both tools now accept a `page` param and return `total_results`, `total_pages`, `page`, and `page_size` — matching the pattern used by get_transactions and get_holdings. Adds a migration for composite (family_id, name) indexes on tags and categories to support efficient paginated ordering within a family scope. * fix(mcp): make page param optional in get_tags/get_categories schema and fix migration version Page defaults to 1 in call() so marking it required in the JSON schema was incorrect. Also fixes migration to use ActiveRecord::Migration[7.2] instead of [8.0]. * fix: update schema.rb with family_id+name indexes for tags and categories * fix(mcp): stable pagination sort and unique family/name indexes on tags and categories - Make family_id+name indexes unique (matches existing AR uniqueness validations) - Add id tie-breaker to alphabetically/alphabetically_by_hierarchy scopes so paginated results are deterministic * refactor(mcp): replace Pagy::Backend mixin with Pagy.new in model layer Pagy::Backend is designed for controllers; using it in plain model classes is fragile. Switch all four assistant functions to call Pagy.new(count:, page:, limit:) directly and apply offset/limit on the scope, which is the correct approach for non-controller contexts.	2026-08-12 23:55:05 +02:00
Guillem Arias Fauste	344cf091e1	feat(auth): sign in with a passkey, without a password (#2911) ... * feat(auth): sign in with a passkey, without a password Passkeys could only ever replace the TOTP code: registration required 2FA to already be on, and the WebAuthn ceremony was reachable only after User.authenticate_by had succeeded. A registered passkey can now complete sign-in on its own, from the login page. The ceremony requests userVerification: "required", so the authenticator has to confirm the person as well as the device. That makes a lone passkey two independent factors, the same bar as the password plus TOTP flow it replaces, which is why this path deliberately skips the TOTP step. A credential that can only prove presence is rejected here and still works as a second factor. Sign-in is usernameless: no email is submitted, because the browser returns the account handle with the assertion. Nothing on this path can be probed to learn whether an account exists. Registration now asks for a discoverable credential with residentKey: "preferred" so the key is offered by the picker, while authenticators without a free resident-key slot still register as a second factor. Where conditional mediation is available, saved passkeys appear in the email field's autofill menu; everywhere else the button covers it. The automatic challenge request that conditional mediation makes on every page load gets its own looser Rack::Attack budget, so ordinary page views can no longer exhaust the limit that protects the MFA endpoints. Set AUTH_PASSKEY_LOGIN_ENABLED=false to keep passkeys as a second factor only. Passkey sign-in follows the same policy as local login, so it stays closed to regular users when AUTH_LOCAL_LOGIN_ENABLED is false. * refactor(auth): group the passkey button with the other sign-in methods It sat directly under the password fields, so the forgot-password link split it from the identical SSO buttons. It is an alternative to the credential form rather than part of it. * fix(auth): close the passkey challenge races and document the upgrade Three review passes converged on the conditional-mediation flow. The AbortController was created after `isConditionalMediationAvailable()` resolved, so a button click or a Turbo disconnect landing in that window found nothing to abort: the conditional task carried on, re-minted the challenge, and the assertion the user was about to produce verified against a challenge the server had already replaced. It is created before the first await now, and held in a local, because `abortConditionalMediation()` nulls the field. Checking that one signal after each await covers both triggers, so no separate connected flag is needed. The same symptom had a second cause nobody flagged: `authenticate()` was not re-entrant. A double-click minted a fresh challenge under an open authenticator prompt and rejected a perfectly valid passkey, with no race window at all — and it was live on the MFA step-up too, which shares the method. The conditional catch was silent for every failure, including a rejected assertion the user had deliberately chosen from the autofill menu. Splitting the try draws the line where it belongs: silence before the user has been asked anything, feedback once they have picked a passkey. Filtering on `error.name` cannot draw it, since `fetchOptions` and `verifyCredential` both raise a plain Error. Also documents the upgrade: passwordless is on by default and applies to already-registered credentials, so a passkey added purely as a second factor can now sign its owner in alone. Nothing in the schema marks a credential discoverable — the authenticator decides — and the opt-out is instance-wide. The invitation test is a guard, not coverage for this change. The pending token lives in the Rack session and `complete_sign_in` reads it right after creating the session, so a `reset_session` dropped in between strands the invitee in their own family, silently and with every existing test still green. * fix(auth): cancel the in-flight conditional options request Aborting the conditional flow did not cancel its options request, because `fetchOptions` never received the signal. A click landing while that POST was in flight left it to finish, and its response could apply last. The challenge rides in the session cookie, so "the server wrote it" only counts if the Set-Cookie reaches the browser. Threading the signal means an aborted request's response is discarded, which closes the window without needing the server to hold two challenges open. Also drops the absolute claim about which existing credentials gain passwordless sign-in. `residentKey: "preferred"` is a request an authenticator may decline, and nothing records what it decided, so the honest statement is that password managers and platform authenticators generally store discoverable credentials rather than always.	2026-08-12 20:35:13 +02:00
Faldy Ikhwan Fadila	792047b82e	feat(yahoo_finance): add Indonesia Stock Exchange (XIDX) support (#3000) ... Add JKT → XIDX exchange MIC mapping, .JK symbol suffix normalization, IDR default currency, and ID country code for Jakarta exchange. Yahoo Finance returns Indonesian stocks (e.g. BBCA.JK) with exchange code 'JKT'. Without this mapping, the provider cannot resolve the exchange to the XIDX MIC already defined in config/exchanges.yml, and normalize_symbol cannot append the .JK suffix for price lookups. Tested manually: Yahoo Finance search and chart endpoints return valid results for IDX tickers (BBCA.JK, currency=IDR, timezone=WIB).	2026-08-12 07:19:14 +02:00
Pedro Santos	7c56c8e2e8	Enable Banking: progressive date_from fallback on WRONG_TRANSACTIONS_PERIOD (#2992) ... * Enable Banking: progressive date_from fallback on WRONG_TRANSACTIONS_PERIOD Some ASPSPs (e.g. Santander Totta and Activo Bank in PT) reject the transactions window with 422 WRONG_TRANSACTIONS_PERIOD but do NOT return a corrected date_from in the payload. The existing single-shot retry only fires when the API supplies detail.date_from, so for these banks the retry was skipped and the error surfaced as the generic "communication error"; transactions never synced even though the connection and session were valid. This adds a bounded, progressive fallback: when the period is rejected and no corrected date is available, retry with progressively shorter windows (89 -> 60 -> 30 days). The ASPSP-suggested date is still preferred on the first retry, so existing behaviour is preserved. The step-down only moves the window forward, guaranteeing progress and avoiding an infinite loop. Verified on a live instance: Activo Bank went from 0 to 82 transactions imported once the fallback kicked in. Refs #2989 Signed-off-by: Pedro Santos <pedro_santos@outlook.pt> * Address review: forward-only progress across all fallback windows - Accept the ASPSP-suggested corrected date only when it moves the window forward (current is nil or corrected > current), preserving the forward-only retry bound (CodeRabbit). - Skip fallback windows that are not newer than the current date_from and pick the first that advances, instead of bailing out on a stale first candidate. Fixes the case where an initial/user lookback (e.g. 45d) is newer than the first window (89d) but the bank caps at 30d (Codex). Signed-off-by: Pedro Santos <pedro_santos@outlook.pt> * Add tests for progressive transactions date_from fallback Covers the two cases the previous single-shot retry missed: - WRONG_TRANSACTIONS_PERIOD without a corrected date_from -> falls back to the first shorter window (89 days). - An initial lookback newer than the leading windows (45d) -> skips the 89/60 windows and retries with the first that advances (30 days). Signed-off-by: Pedro Santos <pedro_santos@outlook.pt> --------- Signed-off-by: Pedro Santos <pedro_santos@outlook.pt>	2026-08-12 02:46:51 +02:00
Brandon WolfandClaude Fable 5	00b7252fbf	feat(mcp): Add MCP budget update tool (#2908) ... * feat(mcp): Add MCP budget update tool Adds an update_budget assistant/MCP function so AI assistants can write monthly budgets: total budgeted spending, expected income, and per-category allocations in one transactional call. - Month resolution and slug format mirror get_budget (YYYY-MM or MMM-YYYY, custom month start respected); targeting a valid month with no budget row bootstraps it via Budget.find_or_bootstrap, same as the budgets UI. - Category allocations accept an exact (case-insensitive) name or id and go through BudgetCategory#update_budgeted_spending!, so subcategory writes keep the parent total in sync. - All writes in one call share a transaction: an invalid category rolls back a totals change from the same call. - Family-scoped like the budgets UI; amounts validated non-negative. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(mcp): harden update_budget per review feedback - Extract shared month resolution into Assistant::Function::MonthResolvable so get_budget and update_budget can't drift on custom month starts - Run budget bootstrap inside the update transaction so a failed entry no longer leaves a newly created budget behind - Apply explicit parent amounts after subcategory syncs so results don't depend on the caller's array order - Reject non-finite amounts (NaN/Infinity) - Explain the synthetic Uncategorized bucket instead of a generic category-not-found error Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-08-11 23:49:43 +02:00
packetsnscripts	babb039ad1	Fix wise imports only 90 days history on initial setup (#2998) ... * Wise connection get full transaction history and adjust for fees * undo devcontainers change * address comments in PR	2026-08-11 23:21:08 +02:00
FalloutmanandJustin	fc130a1957	fix: add Schwab to SimpleFIN total-basis cost_basis allowlist (#2986) ... Charles Schwab's SimpleFIN feed reports `cost_basis` as the total position cost rather than per-share, violating the spec in the same way Vanguard (#1182) and Fidelity (#1718) already do. Schwab wasn't on the TOTAL_BASIS_INSTITUTIONS allowlist, so the raw total was stored directly into holdings.cost_basis and treated as per-share downstream. Holding#calculate_trend multiplies avg_cost by qty again when reconstructing original cost, so an unadjusted total gets squared by share count — a $46,950 position with a true +55.7% gain rendered as -99.8% / -$19.6M "return" on the dashboard and per-account holdings views. Picks up where #2626 left off: adds the allowlist entry, fixes the now-outdated compliant-institution test case it broke, and adds a dedicated regression test using real observed Schwab payload values. Fixes #2626 Co-authored-by: Justin <justin@local>	2026-08-10 07:20:55 +02:00
William Wei MingandCursor	62fd47def9	Add “Is not equal to” operator for transaction amount rules (#2922) ... * Add not-equal operator for transaction amount rules Enable excluding a specific amount in rule conditions without needing paired greater/less than workarounds (#2882). Co-authored-by: Cursor <cursoragent@cursor.com> * Strengthen amount not-equal absolute-value coverage Include a -100 transaction so != 100 proves both signed amounts are excluded. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-05 19:55:15 +02:00
William Wei MingandCursor	35c0b08f11	Add tags support for transfer transactions (#2921) ... * Add tags support for transfer transactions Expose TagSelect on transfer create/edit so users can classify fund movements; apply the same family-scoped tags to both sides. Co-authored-by: Cursor <cursoragent@cursor.com> * Require annotate permission on both transfer sides for tags Prevent tagging a read-only destination transaction when the user only has write access on the outflow account. Co-authored-by: Cursor <cursoragent@cursor.com> * Restore transfer tag selections on create form errors * Localize transfer create validation error messages --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-08-05 19:47:34 +02:00
UnamedRusandClaude Opus 4.8	8c52e20906	fix(binance): correct base_url for futures api endpoint, start_time param (#2839) ... * Update binance.rb Signed-off-by: UnamedRus <UnamedRus@users.noreply.github.com> * Update binance.rb Signed-off-by: UnamedRus <UnamedRus@users.noreply.github.com> * Update binance.rb Signed-off-by: UnamedRus <UnamedRus@users.noreply.github.com> * Fix parameter naming for get_spot_trades and get_futures_trades Signed-off-by: UnamedRus <UnamedRus@users.noreply.github.com> * Update processor_test.rb Signed-off-by: UnamedRus <UnamedRus@users.noreply.github.com> * reset startTime after fromId * Fix Binance trade sync param conflict with windowed initial fetch Binance rejects fromId combined with startTime/endTime, and an unbounded startTime (default sync ~1yr) exceeds the window cap (spot 24h, futures 7d), so the initial sync could fail or miss trades. Split fetch_new_trades into two non-mixing paths: - incremental (cached trades): fromId-only pagination - initial sync: walk forward in fixed windows (24h spot / 7d futures), clamped to the 6-month futures lookback Add endTime param to get_spot_trades/get_futures_trades. Add tests covering multi-window initial sync and multi-page fromId pagination. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Signed-off-by: UnamedRus <UnamedRus@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-08-04 23:55:18 +02:00
4 people	efb7cc3935	Tooling for the wealth + tax agent harness (#2848) ... * Expose the Statement Vault to external agents over MCP A user wants to manage patrimonial history — a document-backed record of a family's wealth where every figure traces back to the statement it came from — by pointing an external agent harness at Sure. That model belongs in the harness, not in Sure: it needs numbered build deltas, golden tests and closed periods that a mutable Postgres row cannot provide. What Sure was missing was the seam. The Statement Vault already does most of the work — original bytes retained, SHA-256 dedup, period detection, account matching with a confidence score, reconciliation against ledger balances, and a month-by-month coverage map — but it is reachable only from the web UI. An agent could not archive a document, cite one, or check for gaps. Adds five preview MCP tools over what already exists, plus a citation grammar for values the agent writes: - upload_account_statement, list_account_statements, get_account_statement, get_statement_coverage - record_valuation, whose source citation is parsed rather than trusted: ["estimated: "] citation [" (grade: A|B|C)"]. An uncited or free-styled value is rejected at the write boundary instead of landing in the ledger looking authoritative. link and reject are deliberately not exposed. Attaching a statement to an account is the human's decision, and the vault UI is where it is made; the agent reports the suggested match and stops there. Assistant.function_classes now takes a user so preview tools stay out of the default surface. They are hidden from tools/list and not callable by name without the preference enabled, and the vault tools re-check the manager role and per-account permissions, since MCP calls never pass through a controller. Docs: the blueprint this implements, and a guide covering which side owns which layer, the vocabulary map between the two, the monthly runbook, and the gaps (non-user holders, non-statement documents, one value per date). No migrations, no API endpoints, no UI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn * Address review feedback on the vault MCP tools Two non-blocking items from the review pass: Document why get_statement_coverage reads through accessible_by rather than writable_by. It reports which documents exist and writes nothing, so read access is the right bar — and tightening it would hide coverage gaps from people who can already see the figures those gaps sit behind. The comment exists so a future refactor doesn't "fix" it. Close the acknowledged verification gap with tests rather than a one-off manual check. The review noted that nothing proved a real vault payload serializes cleanly out through tools/call — vault responses are richer than the other tools' output, with nested account hashes, decimal balances, dates and a compacted hash. Two integration tests now drive the real /mcp endpoint end to end against a real AccountStatement: one listing it, one uploading bytes and reading back the SHA-256. Permanent regression coverage instead of a smoke test someone has to remember to repeat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn * docs(llm-guides): replace patrimonial blueprint with its final revision Swap the embedded early draft for the authoritative final revision of the wealth + tax modelling blueprint (MIT © 2026 diegomarino): - rename the domain vocabulary: patrimonial -> wealth, fiscal -> tax (tax_data/, the tax layer, tax_runner) - add §9.5 (the intel file: shape, generation, and the capture loop) - tighten worked examples down to placeholders - add the MIT header; keep the in-repo NOTE block (adapted to the new vocabulary) and the filename untouched so cross-links don't break * docs(llm-guides): align agent-harness guide with blueprint + fix reconcile semantics Follow the blueprint rename (patrimonial -> wealth, fiscal -> tax, fiscal_data/ -> tax_data/, "Phase 7 (fiscal layer)" -> "(the tax layer)") so the two docs stop disagreeing on vocabulary. Correct the reconciliation mapping, which conflated two different invariants: - blueprint reconcile-or-abort (§7 pass 3) is parse-integrity (parsed parts == the document's own printed total); Sure's reconciliation_checks is ledger agreement (statement balances vs the ledger). Sure has no parse-integrity check and never aborts. - opening_balance / closing_balance are user-entered, not auto-extracted, so over MCP reconciliation is "unavailable" until a human fills them. - tolerance differs: blueprint 1.00/account-period vs Sure's fixed 0.01. State in the ownership table, the invariants section, the vocabulary map and the monthly runbook that parse-integrity and the abort belong to the harness extractor. * Correct the vault tools' reconciliation claims and citation parsing Review findings from @diegomarino, all verified against the code before changing anything. The reconciliation claim was the serious one. get_account_statement told agents the checks were "the trustworthy part" and returned "the balances read off it" — but nothing reads balances off a document. MetadataDetector never touches them and create_from_prepared_upload! never sets them; they are user-editable fields in the Statement Vault UI. So a statement archived over MCP always came back with an empty check list, which an agent could easily read as "the document agrees with the ledger" when it means "nobody has entered the figures". The description now says so, and the payload carries a reconciliation_note spelling it out for anything reading only the JSON. Also noted that these checks are ledger agreement, not parse integrity: nothing here verifies a document's parts sum to its printed total. Provenance::Citation had two patterns disagreeing about spacing. GRADE_SUFFIX allowed "(grade:A)" but FORMAT required exactly one space, so that citation passed the pre-check and then parsed as ungraded with the grade swallowed into the text — silently discarding the reliability the caller supplied, which is the one thing this parser exists to prevent. list_account_statements downcases content_sha256 before querying. The column is constrained to lowercase hex, so uppercase input could never match, and an agent would read the empty result as "not archived" and upload a duplicate. Its period filters are renamed overlapping_from / overlapping_until, since they match on overlap and the old names claimed otherwise to anyone reading the schema without the descriptions. has_more now explains that there is no cursor and the way forward is a bigger limit or narrower filters. record_valuation no longer overwrites the entry's notes. Re-recording a date would destroy a note a person had written there. Nothing is removed now: an identical citation is a no-op, a changed one is appended, and the trail of what was cited when survives. Detecting "did this tool write that line?" is not possible — almost any prose parses as a valid ungraded citation — so the code does not guess. Minor: accept urlsafe base64 on upload, and explain in the code why record_valuation checks the account ACL rather than the vault manager role, so nobody "tightens" it into the wrong permission later. Tests cover each: the grade-spacing cases both ways, uppercase SHA lookup, overlap window boundaries, note preservation and no-stacking, the unavailable reconciliation note appearing and disappearing, and — per the review — that the download URL's signed id actually expires, rather than trusting the description's claim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn * Repair a bad merge in the MCP controller test The merge of main spliced the incoming `tools/call executes update_transaction` test into the middle of the upload round-trip test, before its closing `end`. That left the file one `end` short, so it did not parse — taking out both `ci / lint` (Lint/Syntax) and `ci / test_unit` (the whole file failed to load). Restores the missing `end`. Both tests are kept as their authors wrote them; nothing else changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn * docs: use wealth history wording (#2885) * Stop the vault tools promising verification they don't perform Three findings from the automated review passes, all confirmed against the code before changing anything. The download URL was dead on arrival for the caller it was built for. Sure serves stored files through Active Storage controllers that config/initializers/active_storage_authorization.rb gates on `viewable_by?(Current.user)` — a signed-in browser session. An MCP client has a bearer token and no session, so following the URL would have redirected to sign-in. Removed it rather than leaving a link that cannot work, and the description now points at search_family_files or the vault UI. Coverage called a month `covered` when a document merely existed. An unreconciled statement is not mismatched, so it took the `covered` branch, and the payload carried nothing to correct the reading — the same "advertised verification that never happened" bug fixed last round in get_account_statement, in a second place. Months now carry their own reconciliation_status, and the description says covered means presence, not agreement. Listing filtered visibility after limiting. Beyond underfilling a page, with no cursor and a 100-row cap an accessible statement behind enough newer invisible ones was unreachable. Visibility now lives in the query, mirroring viewable_by? for a statement manager. Also: rescue unexpected upload failures into a tool error instead of a raw exception string, derive the documented size limit from MAX_FILE_SIZE, list every coverage status in mcp.md, and cover the failed-reconciliation and base64-normalisation branches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn * Keep storage exception detail out of the MCP response The upload_failed message interpolated the exception text, which crosses out to an external agent. A storage failure can carry bucket names, object keys, paths or request details, so the agent now gets a fixed message and the exception stays in the server log. The test asserts the absence of detail rather than pinning the leaked string into the contract. Also fixes a test that did not test what it claimed: the urlsafe-base64 case used a fixture encoding to plain base64, so it exercised the padding branch and never the "-_" translation. It now uses content whose encoding contains both characters and asserts that up front. Renames "rejects content that decodes to zero bytes" to "rejects blank content", which is what it actually covers — Base64.strict_encode64("") is "", which is blank and returns before the decoder runs, so invalid_content is correct and empty_file is not reachable from this path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn * docs: align wealth blueprint review feedback * Correct the harness runbook: parse before publishing The guide told an implementer to archive each document to Sure first and work from there. That strands them. Sure never returns a document's bytes over MCP — Active Storage serves stored files only to a signed-in browser session — and there is no text fallback either, because statements archived through upload_account_statement never enter the vector store, so search_family_files cannot see them. A statement in Sure is metadata to an agent and nothing more. That blocks exactly three blueprint steps, all of them operating on bank and broker statements: the extractors, the parts-vs-printed-total check, and the glyph decoder. Everything else it parses — tax returns, capital accounts, annual accounts — the harness already holds locally. So the order inverts: the harness ingests into its own vault, extracts there with the whole file in reach, and publishes to Sure afterwards. This restores principle 8 rather than bending it — the recurring pipeline reads from the canonical store, and treating Sure as canonical forced a re-fetch the architecture never sanctioned. Both sides hash the same bytes, so the SHA-256 verifies Sure holds the identical document without moving it. Writes down the two consequences: a statement uploaded straight into Sure's UI can be known but never parsed (reliability C or PENDING until a copy reaches the harness), and neither vault backs up the other. Also drops a stale tools-table row still advertising the 15-minute download URL removed earlier, corrects get_account_statement's description where it suggested search_family_files as a fallback it cannot be, and disambiguates "the vault" in the MCP tool table, which is what misled me in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JFDp9HhXDeswadu4cxFojn --------- Signed-off-by: Juan José Mata <juanjo.mata@gmail.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: diegomarino <diegomarino@users.noreply.github.com> Co-authored-by: Sure Admin (bot) <sure-admin@splashblot.com>	2026-08-04 23:33:01 +02:00
Maurício Pólvora	93ba2b8c08	Fix chained assistant tool calls (#2767) ... * Fix chained assistant tool calls * Preserve chained tool context	2026-08-04 23:19:20 +02:00
Guillem Arias Fauste	23e7db4f4d	feat(transactions): surface recently-used categories in the category picker (#2829) ... * fix(transactions): don't crash the rule-prompt flash when clearing a category needs_rule_notification? only checked saved_change_to_category_id? and eligible_for_category_rule?, neither of which accounts for category_id being nil. Clearing a category (Clear category / entryable_attributes category_id: nil) satisfies both, so the caller went on to read transaction.category.name against a nil category and crashed. A rule prompt only makes sense when a category was assigned, not cleared, so bail out early when there's no category to build a rule around. * feat(transactions): surface recently-used categories in the category picker Reframes the recency-vs-muscle-memory question as additive, not either/or: a small "Recent" section pinned above the existing alphabetical list, which stays exactly where it always was below it. Precedent for reordering the primary list by frequency (Office's old adaptive menus, browser-history-style resorting) is a well-known anti-pattern — position drifts under the user's hand. Every picker that does recency well (VS Code's command palette, Spotify, Slack's emoji picker) adds a small separate recent cluster instead. - Category#last_used_at, touched only in TransactionCategoriesController#update — the one place a category is actually hand-picked by a person, as opposed to a rule or import auto-assigning one. - Category.recently_used_for(family:, excluding:, limit:) batches the family-scoped query; dropdowns_controller excludes the already- selected category from the Recent section since it's already pinned to the top of the main list. - "Recent" hides itself the moment a search query is typed — it's a pre-search shortcut, not a second copy of search results. Its rows are force-hidden (not just filtered) so keyboard nav can't land on a row that's invisible only because its ancestor section is hidden. * fix(categories): address review feedback on recent-categories picker - Track last_used_at from every manual assignment path (transaction edit form, categorization wizard bulk-update, create-and-assign), not just the category-picker endpoint. Centralized as Transaction#record_category_usage!, called explicitly from each manual controller action rather than wired to a blanket after_save callback, since rule/import auto-assignment must not count as a "recent" pick. - Give recent-section rows a distinct DOM id (recent_category_option_<id>) from their canonical-list counterpart so aria-activedescendant can't resolve to a hidden duplicate during keyboard nav. - Fix migration to ActiveRecord::Migration[7.2] to match the rest of the repo. - Materialize @recent_categories with .to_a to avoid a redundant query.	2026-08-04 23:03:12 +02:00
3 people	5f0f5ec89d	feat(mcp): Add MCP transaction update tool (#2719) ... * Add MCP transaction update tool * Fix MCP transaction authorization * Ignore Pipelock false positive on SnapTrade token lookup Pipelock scan-diff flags `token = oauth_refresh_token...` as "Credential in URL" even though these are ActiveRecord attribute names, not embedded secrets. Add the established inline ignore. Co-authored-by: Martin Molcrette <Mart1M@users.noreply.github.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Martin Molcrette <Mart1M@users.noreply.github.com>	2026-08-01 20:57:43 +02:00
Guillem Arias Fauste	9d3879a859	feat(plan): unify Budgets and Goals under a single Plan tab (#2687) ... * feat(plan): unify Budgets and Goals under a single Plan tab Preview users get one "Plan" nav entry (compass icon) in place of the separate Budgets and preview-gated Goals items. It fronts a new /plan hub with two summary cards — this month's budget (spent vs budgeted, days left, top categories) and active goals (total saved vs targets, behind/pending counts, per-goal rows) — each drilling into the existing /budgets and /goals pages, whose breadcrumbs now start Home > Plan. The two features share a home, not a model: no schema changes, no URL changes. Users without preview features keep exactly the pre-Plan nav (Budgets entry, Goals hidden), and /plan falls through to /budgets for them. Supporting changes: - Goal.active_prepared_for: index-style sorted active goals with the family-wide pooled-allocations + market-flows injection reused - Goal::FUNDABLE_ACCOUNT_TYPES and Goal::ACTIVE_DISPLAY_STATUS_RANK extracted from GoalsController - Budget#days_remaining (same day math as suggested_daily_spending) - Breadcrumbable#plan_breadcrumb_prefix for the conditional Plan crumb - New BudgetsController web tests (previously untested) + Plans tests * fix(plan): address review feedback on the Plan hub - Keep the "All goals" footer link rendered when the family has only completed/archived goals — the hub is a preview user's only route to the goals index now that the Goals nav entry is gone (Codex P2) - Replace the two hand-rolled footer button-links with DS::Link (variant secondary, full_width, right icon) per DS Drift Patrol - Fix DS::Link template comparing icon_position against the string "right" — the initializer symbolizes it, so right-positioned icons never rendered on links (DS::Button already compared symbols); existing callers passing icon_position now get the layout they asked for - Clamp progress-bar percentages to 0..100 instead of capping only the upper bound (CodeRabbit) * refactor(plan): single source of truth for goal loading, sorting, and counts Addresses jjmata's draft review notes: - GoalsController#index now builds on the shared Goal loaders instead of hand-rolling its own copy: Goal.prepared_for (preloads + family- wide backing-math injection, scope-able) and Goal.active_display_sort carry the algorithm once; active_prepared_for composes them for the hub. The controller-side constant alias is gone - One definition of "behind pace": Goal#behind_pace? (excludes paused — pausing stops the pace clock on purpose). Both the Plan hub summary and GoalsController#kpi_payload's behind/needs-this-month figures use it, so adjacent pages can't disagree. While there, the kpi on-track numerator also excludes paused goals — it was counted against a paused-excluding denominator, so the "X of Y" fraction could exceed its own total - BudgetCategory#suggested_daily_spending calls Budget#days_remaining instead of keeping an inline copy of the day math - Per the fat-model convention, the hub's aggregation moved off the controller: Budget#top_spending_categories(limit:) and Goal.summary_for(goals, currency:) * fix(plan): move Edit budget/New goal into their own cards Both actions lived in the hub's shared page header, unlinked to either card and, on mobile, wrapping above all content before any real data appeared. Each now lives in its own card's header instead: Edit budget as a compact icon-only control next to the status pill (only when a budget exists — the uninitialized state already has its own "Set up" CTA), New goal as a small outline button next to the goals count (only once there's a goal to sit beside; the empty state keeps its own CTA). Also swaps the edit icon from "pencil" to "square-pen" — at the sizes these header controls render, lucide's plain pencil is a thin diagonal stroke that reads noticeably smaller than a neighboring bold glyph like "plus", even in the same size box. square-pen carries more visual mass and reads clearly at the same footprint. * fix(plan): match established DS precedent for the card header actions Edit budget was a bare icon-only button; verified against the app's own precedent for this exact action (app/views/budgets/_budget_donut.html.erb, the budget card already shipped on /budgets) and it's a labeled secondary link with a trailing pencil, not icon-only and not a three-dot menu. Matched that: DS::Link, variant secondary, size sm, icon right. New goal gets the same treatment for consistency between the two cards' header actions, rather than the full-page-scoped "primary" weight goals/index.html.erb uses for its own create button — that's calibrated for a whole page's sole CTA, not a compact card. Adding a labeled button (wider than the bare icon this replaces) crowded the header row on mobile enough to wrap "This month" onto two lines and truncate the "· July 2026" meta away entirely. Header rows now wrap as a whole (flex-wrap) with the title pinned (shrink-0) so the action cluster drops to its own line instead of squeezing the title and meta text. Also drops the hub's footer note ("Budgets cap your spend; goals track what you're saving toward...") — redundant with the subtitle right above the cards. * fix(plan): lead the budget card header with status, not the edit action On Track/Over/Warning is what a glance at the card wants first; Edit budget is the secondary action. Swapped their order so status leads and the edit control trails, gap-2 unchanged. * fix(plan): put the status pill on the left, next to the title Meant the left side of the card, not just left of the edit button. On Track/Over/Warning now sits beside "This month · July 2026" in normal flow; ml-auto carries only the Edit budget link, alone on the right — matching the goals card's own left-meta/right-action split ("· 7 active" left, "New goal" right). * fix(plan): lead Edit budget with its icon, matching same-shape precedent Wrong axis on the earlier match: _budget_donut's trailing pencil labels the VALUE itself ("$12,850 ✎"), not a static action. Our button's label is a static "Edit budget", and that shape takes a leading icon everywhere else it appears — the categories "Edit" on budgets/show.html.erb (icon: settings-2) and "Edit split" in transactions/show.html.erb both lead with their icon. Drops icon_position: :right so it defaults to left, matching New goal's shape in the sibling card. * fix(plan): use the divider token for row separators, not border-primary Traced against the dashboard outflows list (pages/dashboard/_outflows_donut.html.erb), which renders its row separators via shared/_ruler → border-divider (border-tertiary: black/8%, white/10%). Our category and goal rows used border-b border-primary instead (black/15%, white/30%) — 2-3x heavier than the established row-separator weight elsewhere in the app. Swapped both to border-divider. * fix(plan): lift the duplicated card shell into DS::Card Codex P1: _budget_card.html.erb and _goals_card.html.erb hand-rolled the identical "bg-container rounded-xl shadow-border-xs p-5 flex flex-col" shell twice, with no DS:: card primitive to reach for instead. Extracted a minimal wrapper — content-only, no header/footer slots — matching what both cards actually need right now; the roadmap cards (envelopes #2153, retirement #2044) can adopt it too instead of copying the class string a third time. Verified pixel-identical in a browser: same classes, same DOM shape, just rendered through the component. * fix(plan): batch pace queries before sorting goals Codex P2: active_display_sort calls goal.status per goal to build the sort key; Goal#status reaches Goal#pace for any goal with a target_date, which fired its own Entry.sum(:amount) query per goal. The /plan hub renders only the first 5 of active_prepared_for's list, but paid the full O(N) query cost sorting all of them. Adds Goal.pace_for(family) (account_id => 90-day net inflow), grouped in one query and injected via inject_backing_math! alongside the existing pooled_allocations/market_flows pattern. #pace now sums from that shared map instead of firing its own query — same math, same 90-day window, same exclusions, just computed once per family instead of once per goal.	2026-08-01 08:51:08 +02:00
Guillem Arias Fauste	59852ca0f3	fix(insights): respect recurring_transactions_disabled in subscription_audit (#2831) ... * fix(insights): respect recurring_transactions_disabled in subscription_audit SubscriptionAuditGenerator queried family.recurring_transactions directly, so disabling recurring-transaction detection (Settings -> Recurring Transactions) never stopped already-identified rows from surfacing "recurring charge overdue" insights on the Insights feed — the family-wide flag was already checked at both call sites in IdentifyRecurringTransactionsJob, just not here. Returning [] early is enough for existing insights to self-clean up: produced_types is a class-level declaration, so GenerateInsightsJob still counts subscription_audit as a succeeded type and expires any insight whose dedup_key wasn't regenerated on the next nightly run. * docs(insights): document why cash_flow_warning skips the recurring-disabled guard Answers jjmata's open review question. Unlike SubscriptionAuditGenerator, recurring transactions here are one input into a broader cash-flow projection, not the insight's entire subject — so it intentionally keeps using the last-known identified set rather than gating on family.recurring_transactions_disabled?. No behavior change.	2026-08-01 08:47:50 +02:00
kai392andClaude Opus 4.8	73aac31f89	fix(exports): include merchants.csv in family data export (#2758) ... * fix: include merchants.csv in family data export The family export ZIP contained CSVs for accounts, transactions, trades, categories, and rules — but merchants were only present inside the all.ndjson bulk file, never as a standalone merchants.csv. Meanwhile merchants can already be imported via CSV (MerchantImport), so backups were lossy and the import/export cycle was asymmetric. Add generate_merchants_csv to Family::DataExporter, wired into the export ZIP, with headers (name,color,website_url) matching exactly what MerchantImport expects so the exported file round-trips. Fixes #2736 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: fix merchants CSV round-trip assertion for family fixtures The round-trip test asserted the target family's total merchant count grew by exactly 1, but the export legitimately includes every family merchant — including dylan_family's fixtures — so the import created 4, failing CI. Scope the count assertion to the merchant under test. Also assert the imported color now that merchant colors survive a save (the set_default_color callback only backfills when no valid color is present), giving the round-trip full name/color/website coverage. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-08-01 08:45:14 +02:00
Carlos Lindo	ef61466e87	fix(enable-banking): preserve manual card limit when provider reports zero (#2841) ... * Preserve manual card limit when provider reports zero * Test non-positive provider credit limits * Address credit limit review feedback	2026-08-01 08:44:30 +02:00
Guillem Arias Fauste	c40e7f4807	fix(insights): correct the budget card's figure, badge noise and toast a11y (#2799) ... * fix(insights): correct the budget card's figure, badge noise and toast a11y Four defects found while reviewing the insights surfaces for hierarchy. **The budget_at_risk card's focal figure argued against its own headline.** `insight_key_figure` returned `budget_spent_pct` for both budget cards, so "2 categories need attention in your budget" displayed "14% / of budget" — a reassuring number as the visual focus of a warning. It now leads with the flagged count ("2 / need attention"); budget_on_track keeps the percentage, where overall consumption genuinely is the subject. **The "New" pill carried no information.** Visiting /insights marks every insight read in one `update_all`, so at first paint the pill was on every row. On the page it becomes a dot — same signal, without an uppercase tracked chip stealing weight from the title beside it. In the dashboard widget it goes entirely: the well's header already counts unread ("New · 3") and, with three rows, the pill was usually on all of them. **The undo toast was silent to screen readers.** A card leaves the page via a Turbo `remove`, which announces nothing, and the toast that explains it had no live region — unlike its neighbour `_sync_toast`, which sets `role="status" aria-live="polite"`. **The undo toast could only be closed with a mouse.** Its close affordance was a bare `icon "x"` with a click action: not focusable, not named. Now a real `DS::Button`, matching `_sync_toast`. The controller test asserting a per-row badge is updated to assert the header count that replaces it, and to lock in the pill's removal. * feat(insights): acknowledge instead of dismiss, on both surfaces (#2800) Two complaints about the insight feed: the close (×) control felt wrong, and clearing an insight was only possible on /insights — not on the dashboard widget, which is the surface people actually look at. **The × was lying.** Dismissal has never been permanent. GenerateInsightsJob resurfaces a row whose bucketed metadata changes materially "even if the user had read or dismissed the stale version" (its own comment), and 6 of 8 generators scope dedup_key to a month token, so dismissing July's budget card says nothing about August's. A destructive-looking control was performing a non-destructive act. It is now "Got it", and the contract is statable: acknowledgement covers the numbers you saw; new numbers are a new insight. No migration. The DB value stays "dismissed" and dismissed_at keeps its name; only the enum key and the vocabulary the code speaks change, so existing rows stay hidden and become undoable under an honest label. **The action pyramid was inverted.** The escape hatch was a chromed icon button in the card's top-right — the strongest secondary scan position — while the card's actual purpose ("View budget") was a borderless ghost link under the body text. Both now sit in a footer strip: the subject action gets the chrome, acknowledging is quiet labelled text beside it, and the key figure gets the corner to itself instead of competing with a control. **The widget can clear its own rows.** Each row gains an acknowledge control, revealed on pointer hover, on keyboard focus, and shown unconditionally on touch where there is no hover. No gesture, so the section's drag-to-reorder handlers are untouched. The row becomes a stretched link plus a sibling button, because button_to renders a <form> and a form cannot nest in an <a>. The group is named (group/insight). The dashboard <section> is itself a `.group` for its header controls, and a bare group-hover: matches any ancestor group — hovering one row, or the section header, revealed every row's control. Acknowledging re-renders the well rather than removing a row, so the next insight is promoted into the freed slot; Insight::FEED_LIMIT is now shared between the two controllers that render it so they cannot drift. Undo restores the row on both surfaces, and carries autofocus so it is one keystroke away after the acknowledged card leaves the DOM. * fix(insights): guard unacknowledge! against non-acknowledged insights CodeRabbit, Major: an arbitrary/stale PATCH /unacknowledge (e.g. an old undo-toast link clicked after GenerateInsightsJob has since expired or resurrected the insight) could force it back to :read regardless of its actual current state — including pulling an :expired insight back into visible view. Guards the transition to only reverse an actual acknowledgement, per CodeRabbit's suggested fix. * test(insights): fix stale dismiss_insight_url route from main merge main's preview-gate test used the pre-rename dismiss/undismiss route names; this branch renamed those to acknowledge/unacknowledge earlier.	2026-08-01 08:39:04 +02:00
Gerald	9313ad4cba	fix: tolerate Trade Republic Enable Banking pagination/PDNG errors (#392) (#2828) ... * fix: tolerate Enable Banking pagination/PDNG errors for Trade Republic Trade Republic (available via Enable Banking since ~2026-07-22, see #392) fails to sync with two distinct errors on its own side: 1. The BOOK transaction fetch issues a continuation_key on page 1 that its own API then rejects on page 2 as mismatched with transaction_status (422 WRONG_REQUEST_PARAMETERS: "transactionStatus in request is not the same as in continuationKey"). This previously discarded every page already fetched. Once at least one page has succeeded, a validation error is now treated as pagination exhausted and the partial result is kept instead of raising. A validation error on the very first page still propagates as a real failure. 2. The PDNG (pending) fetch is rejected with a plain 400 (:bad_request) instead of the 422 (:validation_error) other ASPSPs use for the same "transaction status not supported" case. Both error types are now treated as "ASPSP doesn't support pending transactions". Verified against a live Trade Republic connection through Enable Banking. * fix: surface Enable Banking pagination truncation as a debug log entry Add a DebugLogEntry.capture call when a mid-pagination validation error truncates the transaction fetch (e.g. the Trade Republic continuation_key bug from the previous commit). This follows the project convention of using DebugLogEntry for support-relevant sync diagnostics rather than only Rails.logger, so a truncated sync is visible in /settings/debug instead of only in container logs. Currently harmless for narrow incremental sync windows (the account observed in production has under 100 transactions per window, fitting entirely on page 1), but a wider historical resync could otherwise lose data past page 1 with no visible indication. * fix: address CodeRabbit review feedback on PR #2828 - Add a DebugLogEntry when the PDNG fetch is skipped as unsupported, matching the pattern already used for pagination truncation — this was a partial-degradation case that was previously only visible via Rails.logger. - Replace the OpenStruct#define_singleton_method provider fakes in the three new pagination tests with sequenced Mocha stubs (expects(...).twice.returns(...).then.raises(...)), per the project's "use Mocha for stubs and mocks" guideline. * fix: don't swallow WRONG_TRANSACTIONS_PERIOD as pagination truncation The mid-pagination validation-error handling treated any 422 after page one as "ASPSP rejected the continuation key" and kept the partial result as a success. WRONG_TRANSACTIONS_PERIOD is a different, real failure (an invalid date range, already retried once with a corrected date_from at the provider level) and must still propagate instead of silently dropping the remaining pages. Addresses CodeRabbit review feedback on PR #2828. * fix: address jjmata's review feedback on partial-result asymmetry - fetch_paginated_transactions now tolerates :bad_request the same way it already tolerates :validation_error mid-pagination, matching the PDNG-unsupported rescue in fetch_and_store_transactions which already accepts both error types. Without this, a :bad_request on PDNG page 2+ would discard the already-fetched PDNG page 1 instead of keeping it like the BOOK path does. Trade Republic only 400s on PDNG page 1 today, so this was latent, not currently observed. - Bump the pagination-truncation log (Rails.logger + DebugLogEntry) from warn to error: this now discards data for any ASPSP/scenario matching the tolerated error types mid-pagination, not just the specific Trade Republic case it was written for, so it deserves higher visibility. - Add a regression test for :bad_request interrupting PDNG pagination on page 2+, pinning down the now-symmetric behavior with BOOK.	2026-08-01 08:27:59 +02:00
Sure Admin (bot)	1e800e2f93	Include uncategorized spending in budget UI (#2877)	2026-08-01 07:50:09 +02:00
Maximus Barbare	4c1bc774e5	Fix SnapTrade account setup and reconnection (#2858) ... * Infer SnapTrade account types from categories * Allow choosing SnapTrade account types * Reauthorize SnapTrade connections needing attention * Clear stale SnapTrade reconnect state * Always schedule SnapTrade reconnect syncs * Recognize SnapTrade credit card accounts * Recognize SnapTrade crypto account types * Schedule SnapTrade syncs after active imports * Fix SnapTrade account type CI tests * Normalize SnapTrade card account types	2026-07-31 02:20:03 +02:00
sentry[bot]andsentry[bot] <39604003+sentry[bot]@users.noreply.github.com>	32eef8e2ea	Fix(exchange_rate): Handle RecordInvalid in find_or_fetch_rate race condition (#2734) ... Co-authored-by: sentry[bot] <39604003+sentry[bot]@users.noreply.github.com>	2026-07-30 03:05:14 +02:00
Guillem Arias Fauste	cedf28a5a9	fix(accounts): make the sync toolbar and toast agree, fix toast overlap (#2813) ... * fix(accounts): make the sync toolbar and toast agree, fix toast overlap The Accounts page's own sync toolbar (refresh icon, "Cancel sync") and the global sync-complete toast were three inconsistently-styled, disconnected pieces of UI representing one action, and the toast overlapped the page's own header instead of sitting near it. - "Cancel sync" was hand-rolled markup instead of a DS::Button, unlike its sibling refresh icon right next to it — now both are DS::Button (:ghost). - The refresh icon just went `disabled` with no visible "working" state — now shows a spinning loader-circle while a family sync is in progress, matching the pattern already used in provider_sync_summary.html.erb. - The toolbar was plain server-rendered HTML with no way to know a sync finished, so it stayed stuck showing "still syncing" indefinitely next to a toast now saying otherwise. Family::SyncCompleteEvent now broadcasts a second replace target for the toolbar alongside the existing toast replace, so both resolve together. - The notification tray was a <body>-level fixed overlay centered on the full viewport, but every layout that renders it has a sidebar of some kind — so it never actually centered on the visible content pane, and landed on top of the settings-layout header. It now renders in-flow at the top of each layout's own content region (opt-in via notification_tray_inline, since the simpler single-column layouts don't have this mismatch and are unaffected). - Added the Catalan sync_toast/cancel_sync strings that were missing entirely, which is why the toast/toolbar showed English text on an otherwise-Catalan page. Verified live in a real browser via a new system test covering the idle, syncing, and cancel-flash states, plus a model test on the new broadcast target. * fix(accounts): keep the tray a floating overlay, sidebar-aware instead Codex on this PR: with the tray as first-child-of-scrollable-main, a notification delivered while scrolled down is inserted above the viewport and stays unseen — breaking the sync toast's manual-refresh path specifically, since sync_toast_controller.js suppresses auto-refresh while a form is focused and relies on the toast being visible to offer that manual refresh. Reverts the tray to a position: fixed overlay for every layout (so it can't be scrolled out of view), and fixes the actual bug that made it overlap the accounts toolbar in the first place — a ResizeObserver on <main> centers it on the real content pane instead of the viewport, for the two layouts with a sidebar (application, settings passed via sidebar_aware:). The five single-column layouts are untouched; for those, viewport-center already is content-pane-center. One trap worth flagging: this app renders turbo_refreshes_with method: :morph, and idiomorph resets any inline style a client script set that isn't in the freshly-fetched HTML — including the JS-set `left`. data-turbo-permanent looked like the fix but isn't: it invokes idiomorph's node-identity matching (same id preserved across ANY morphed page), which broke navigation once the id existed on structurally different layouts (app vs settings) — a real, reproduced bug, caught by the system test before it shipped. Went with the narrower turbo:before-morph-attribute event instead, which blocks only the `style` attribute on this one element, with no node-identity system involved. Rewrote the system test's positioning assertion to match: it now asserts the tray centers on <main> rather than sitting above the page header, since a fixed overlay was never going to satisfy the latter by construction. Verified: full bin/rails test (6023 runs, 0 failures), rubocop, erb_lint, brakeman (0 warnings) all clean. Live-verified in a browser across both sidebar-aware layouts and a simple layout, including the full cancel-sync -> morph -> re-render cycle. * fix(accounts): use declarative Stimulus action for morph-attribute guard Replace the manual addEventListener/removeEventListener pair for turbo:before-morph-attribute with a data-action, per the repo's declarative-actions convention. Same element, same listener — just no manual lifecycle management.	2026-07-30 02:57:16 +02:00
Otter	1c6d018b6a	Fix transactions posting a day early when booked around midnight. (#2744) ... * Fix 2668 * Fix CodeRabbit nitpick * Fix Akahu parsing * Anchor provider transaction date parsing to family timezone * Coderabbit suggestion for Date/DateTime order * Remove duplicate condition in wise * Safe unless column_exists + pass family to date parse to family components	2026-07-30 02:29:13 +02:00
PrplHaz4andClaude Fable 5	16d2bc0ce9	Don’t re-create pending SimpleFIN transactions when pending sync is disabled (#2835) ... * fix(simplefin): skip pending entries in processor when pending is disabled When SIMPLEFIN_INCLUDE_PENDING/syncs_include_pending is off, pending rows already stored in raw_transactions_payload were still (re)created as entries on every sync - including ones the user manually deleted - because the setting only affected the API request, not reprocessing of the stored payload. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(simplefin): add rake task to prune stale pending rows from payload store raw_transactions_payload accumulates transactions across syncs and is never pruned, so pending rows fetched before pending inclusion was disabled keep getting re-imported. This one-time maintenance task removes them (dry-run by default; scope by item_id/account_id). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(simplefin): address PR #2835 review feedback on pending detection Fix epoch-zero pending check treating non-numeric posted strings (e.g. "unavailable") as pending via String#to_i coercion; compare against explicit zero representations instead, matching posted_date. Dedupe the prune_pending rake task's copy of this logic by delegating to a new public SimplefinEntry::Processor.pending? class method. Also close a test gap where SIMPLEFIN_INCLUDE_PENDING env var precedence over the Setting wasn't actually exercised. * test(simplefin): cover pending-guard precedence and add rake task tests Add the missing mirror case for pending_enabled? precedence (env var disabling pending over a permissive Setting) and add test coverage for the prune_pending rake task, which previously had none: dry_run safety default, correct pruning via the shared Processor.pending? predicate (including the malformed-posted regression), and that it never touches Entry/Transaction rows. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 01:13:02 +02:00
Oscar	c6a240a183	feat(redbark): add australian bank sync (redbark) (#2794) ... * add redbark provider integration - per family api key provider, built like the lunchflow integration - syncs accounts, balances and transactions from api.redbark.com - account setup flow, settings panel, locales and routes - tests and fixtures * harden redbark integration based on prior provider pr feedback - use DebugLogEntry.capture for sync/import/unlink failures - retry 429s and 5xxs with backoff, raise on page cap instead of truncating - keep raw response bodies out of logs and errors - not null constraints on account columns, migration base 7.2 - persist ignored flag for skipped accounts so they stop nagging setup - validate api key on every save, re-arm status on key rotation - destroy aborts if unlink fails, atomic account create and link - require_admin on mutating actions, see_other on error redirects - single grouped query for item account counts - i18n default connection name, blank password field value - controller and provider tests * fix issues found in second review sweep - add missing syncable scope, without it every family sync raises - kick off a sync on connection create and on key rotation - setup dialog fetches accounts inline for fresh connections and shows api errors - skip balance write when no balance has been fetched yet, never anchor a false zero - exclude stale and non banking accounts from the batched balances call, per account fallback if the batch is rejected - detect the server row ceiling and empty pages instead of silently truncating history - user sync start date only governs the initial backfill, incremental after that - fetch connections before the per account loop so auth errors propagate once - drop untemplated index/show/new/edit routes and dead preload/link_accounts actions - stable dom id on the settings panel so repeat turbo replaces keep working * skip brokerage connections, found in live testing - the transactions endpoint 400s for brokerage connections, they belong to /v1/trades - only import accounts from banking and documents connections - guard transaction fetches for any legacy linked non banking account * address review feedback - treat the truncation header as a pagination signal: split the date window and refetch instead of failing the account - prune stale pending rows from the snapshot so settled pendings cant come back as duplicates - block linking a sure account that already has another provider feed - count setup failures separately from skips and surface an error instead of "all skipped" - add not nulls on redbark_items name and api key - enqueue the destroy job after the flag commits, not inside the transaction - swap bg-gray-400 for bg-surface-inset, drop amounts from info logs, remove i18n default fallbacks - tests for window splitting, pending pruning and encrypted payload round trip * fix issues from convention review - benign skips (unlinked account, blank id, unparseable rows) no longer count as failures, tracked separately so a clean batch reports success - currency parsing goes through extract_currency so hash shaped payloads resolve instead of falling to the default - merchant ids use truncated sha256 instead of md5 - debug log entries for import failures and account sync scheduling failures * bound the raw transactions snapshot to the fetch window - trim raw_transactions_payload to the current fetch window on merge, same as brex - keep rows without a parseable date, drop settled pendings as before - surface skipped rows in the aggregate debug log entry with imported/skipped counts	2026-07-26 07:40:25 +02:00
3 people	375dd060dc	feat(insights): gate the insights feed behind preview features (#2788) ... * feat(insights): gate the insights feed behind preview features Insights shipped to everyone in #2550. Make it opt-in via Settings → Preferences until it's proven, so users who haven't enabled preview features see nothing and cost nothing. Entry points gated: - InsightsController — require_preview_features! covers all four actions, including the refresh action that enqueues the job - Dashboard — the insights_feed section is omitted from the section list rather than left in it hidden, so the saved-order lookup and the insights_feed unshift special-case never fire; the feed query is skipped - Top bar — the lightbulb entry and its unread COUNT, which previously ran on every page render The job is gated too, departing from the guide's default that background jobs keep running. That default fits a job like SweepExpiredGoalPledgesJob, which only walks records opted-in users created and is naturally inert. GenerateInsightsJob instead manufactures data for every family nightly — seven generators over the income statement and balance sheet, plus paid LLM narration — so it would have kept spending on families who can't see the result. The fan-out filters with Family.with_preview_features (one indexed jsonb containment query, not load-and-iterate), and generate_for_family re-checks above the advisory lock so a gated family skips the broadcast too. Adds Family#preview_features_enabled? and the matching scopes, keeping the predicate name identical on User and Family so the guide's GA-removal grep finds every call site. Verified the SQL scope and the Ruby predicate agree for true / false / "yes" / nil. Documents the job-gating pattern in docs/llm-guides/gating-a-preview-feature.md, which previously said the gate does nothing for jobs. Existing insight rows are left alone: invisible without the flag, and the next nightly run refreshes facts and expires anything stale if a family opts in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6ZRA6cgCRM4UdFKct3wm4 * perf(insights): use EXISTS for the family preview rollup Family#preview_features_enabled? is asked once per family by the nightly job; the block form loaded and instantiated every member to answer a boolean. Delegate to the scope instead. The predicate now shares an implementation with the scope, so the truthy-non-boolean test asserts against User#preview_features_enabled? — the predicate the UI actually gates on — to keep the cross-check meaningful rather than tautological. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6ZRA6cgCRM4UdFKct3wm4 * docs(insights): fix guide/code drift and stale cron description Review follow-ups from @gariasf: - The guide's family-rollup snippet still showed the block form after the EXISTS commit changed it. It mattered more than normal doc drift: the paragraph below calls GenerateInsightsJob "the reference implementation", so the next person writing a gated job would have copied the form family.rb's comment explicitly rejects. - schedule.yml still described the job as running for "all families" — the string someone reads while debugging why a family got no insights. - Document that the shared predicate name is per-user on User but "anyone in the household" on Family, and prohibit gating UI on the family form: Current.family.preview_features_enabled? reads naturally and would show the feature to a user who explicitly opted out. Noted in both the model and the guide. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6ZRA6cgCRM4UdFKct3wm4 --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Guillem Arias Fauste <accounts@gariasf.com>	2026-07-26 07:18:23 +02:00
kai392andClaude Opus 4.8	6e2cbb727a	fix(ai): prevent Anthropic chat crash on no-argument tool calls (#2755) ... * fix: prevent Anthropic chat crash on no-argument tool calls When the model streams a tool_use block with no arguments (e.g. get_categories), the accumulated input arrives as an empty string. The Anthropic chat parser passed that empty string straight through as function_args, and Assistant::FunctionToolCaller then called JSON.parse("") — which raises "unexpected end of input", surfaces as a Provider::Anthropic::Error, and kills the whole assistant turn. Fix at the source by normalizing empty/nil tool input to an empty JSON object in the parser, plus a defensive guard in FunctionToolCaller so any provider that emits blank arguments cannot crash a turn. Fixes #2722 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: assert nil-args result as Hash to match jsonb function_result Addresses Codex P1 / CodeRabbit review: EchoFunction returns the parsed params Hash and ToolCall::Function stores it in a jsonb column, so the nil-arguments test must assert the Hash directly instead of JSON.parse. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-26 04:47:15 +02:00
RealDiligentandClaude Opus 4.8	d61ee3abea	fix: omit SimpleFin pending param when pending transactions are disabled (#2796) ... The SimpleFIN protocol only defines pending=1 (include pending); pending transactions are excluded by default when the param is absent. Bridges presence-check the param, so the pending=0 we sent when the 'Include pending transactions' setting (or SIMPLEFIN_INCLUDE_PENDING=0) was disabled behaved exactly like pending=1, making the setting a no-op — pending transactions kept being downloaded, causing pending/posted duplicates and churn. Omit the pending query param entirely unless pending is enabled, per the spec. Fixes #2440 Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-26 01:56:42 +02:00
Erkan Doğananderkdgn	1fb5202495	fix(indexa_capital): correct cash activity amount-sign convention (#2793) (#2801) ... Fixes #2793. ## Problem IndexaCapitalAccount::ActivitiesProcessor#normalize_cash_amount used the inverted amount-sign convention relative to Sure's core conventions. - Outflows (WITHDRAWAL, TRANSFER_OUT, FEE, TAX) were stored as negative amounts. - Inflows (CONTRIBUTION, TRANSFER_IN, DIVIDEND, DIV, INTEREST) were stored as positive amounts. Sure requires asset account inflows to be stored as negative amounts (-amount.abs) and outflows as positive amounts (amount.abs). ## Fix Flip signs in IndexaCapitalAccount::ActivitiesProcessor#normalize_cash_amount to align with Sure's sign convention and sibling processors (SnaptradeAccount::ActivitiesProcessor). ## Test Added unit tests in test/models/indexa_capital_account/activities_processor_test.rb covering cash inflows, outflows, transfers, fee, label mappings, and empty payloads. All tests pass (39/39 for indexa_capital_account). Co-authored-by: erkdgn <erkdgn@users.noreply.github.com>	2026-07-26 01:47:53 +02:00
Erkan Doğananderkdgn	71106f63b0	fix(merchants): preserve user-selected merchant colors on save (#2760) (#2802) ... * fix(merchants): preserve user-selected merchant colors on save (#2760) Fixes #2760. ## Problem FamilyMerchant#set_default_color callback ran on before_validation and unconditionally executed self.color = COLORS.sample. As a result: - Any user-selected color or color passed via API/import was discarded and replaced with a random palette color. - Renaming or updating any merchant field re-assigned a new random color on every save. ## Fix Guard set_default_color so it only assigns a random palette color when color is blank (self.color = COLORS.sample if color.blank?). ## Test - Added test/models/family_merchant_test.rb testing color preservation on creation and update, as well as default color fallback when blank. - Updated test/controllers/family_merchants_controller_test.rb to assert persisted color on create and update. - Verified in dev container: 9 runs, 22 assertions, 0 failures, 0 errors. - RuboCop: 0 offenses. * fix(merchants): validate hex format and fallback to default color if invalid Add hex format validation (/\A#[0-9A-Fa-f]{6}\z/) to FamilyMerchant#color (matching Category and Tag models) and ensure set_default_color replaces invalid hex values (e.g. from API/CSV imports) with a default palette color before saving. Responds to Codex review feedback on PR #2802. --------- Co-authored-by: erkdgn <erkdgn@users.noreply.github.com>	2026-07-26 01:38:31 +02:00
Antoine 🚀🏃‍♂️andAntoine GUYON	6b6ae0ca31	feat(accounts): add Gains / ROI chart view for investment accounts (#2660) ... * feat(accounts): add Gains / ROI chart view for investment accounts Adds a fourth chart view to the account details page showing the historical unrealized gains series (market value - cost basis per holding, summed daily with LOCF and FX conversion), following the same ChartSeriesBuilder/Series pipeline as the existing views. Holdings without a usable cost basis (nil, or unlocked zero from providers) contribute zero gain, matching Holding#avg_cost semantics. * fix(accounts): carry cost basis forward over gap-filled holdings in gains series Gap-filled holding rows (weekends, price-history gaps) are persisted without cost_basis even though the position and basis are unchanged, which zeroed the gains series on those dates. Look up the basis from the latest snapshot that has a usable one instead of reading it from the current row, so already-persisted gap-filled rows are handled too. * docs(accounts): add method docstrings for gains chart view code Satisfies the pre-merge docstring coverage check on methods added or touched by the Gains / ROI feature. * fix(accounts): sign converted amount like main indicator in gains view Extracts the gains sign-prefix logic into a shared signed_format helper so the family-currency converted amount shown on foreign-currency accounts matches the main indicator (+€79.53 / +$85.00), and adds component tests covering the positive, negative, non-gains and foreign-currency formatting paths. * test(accounts): cover FX conversion path in gains series The gains_series tests only used USD holdings against a USD target, leaving the exchange_rates LATERAL join untested. Adds a case with EUR holdings converted to USD, including LOCF rate carry-forward. --------- Co-authored-by: Antoine GUYON <agy@ibanfirst.com>	2026-07-25 20:14:56 +02:00
3 people	12b040e47e	fix(akahu): pull full history on initial Akahu sync (#2779) ... * fix(akahu): pull full history on initial Akahu sync Akahu-linked accounts only pulled ~90 days of history on their first sync. Provider::Akahu#fetch_all already walks the full range via Akahu's cursor pagination, so the paging logic was not the limit. AkahuItem::Importer#determine_sync_start_date clamped the initial window to 90.days.ago when an account had no stored transactions and no configured sync_start_date, and Akahu's transactions endpoint only returns data from the requested start onward, so that fallback capped the first import at 90 days. Request a 5.years lookback on the first sync instead. Incremental syncs still continue from last_synced_at - 7.days, and an explicitly configured sync_start_date still takes precedence. Fixes #2609 * fix(akahu): omit start date on initial sync to pull full history determine_sync_start_date still clamped the first import to INITIAL_SYNC_LOOKBACK.ago (5 years), truncating Akahu apps/accounts that can access more history. Akahu's account-transactions endpoint defaults to the entire accessible range when start/end are omitted, so the no-config/no-stored-transactions case now returns nil (no start date). Subsequent syncs still use the incremental last_synced_at - 7.days path. Removes the now-unused INITIAL_SYNC_LOOKBACK constant and updates the test to assert the initial sync omits the start date. --------- Co-authored-by: agentloop <agentloop@localhost> Co-authored-by: pro3958 <pro3958@users.noreply.github.com>	2026-07-25 20:11:25 +02:00
Erkan DoğanandClaude Opus 4.8	32ab402d38	fix(snaptrade): sign bare TRANSFER activities by provider direction (#2792) ... SnapTrade delivers payroll-deducted 401k contributions as type "TRANSFER" rather than "CONTRIBUTION", which normalize_cash_amount did not handle. The value fell through to the pass-through branch and was stored positive, violating the convention that inflows to an asset account are negative. That stored sign drove both reported symptoms. Entry#classification reads a positive amount as an expense, so the row rendered -$1,320.75 while the brokerage showed +$1,320.75. Balance::ReverseCalculator reads it as a value decrease, so walking backward from the provider-anchored current balance produced a steadily declining history despite a correct present-day total. TRANSFER_IN and TRANSFER_OUT encode direction in the type and can force the sign with .abs. A bare TRANSFER does not, so the provider's sign is the only directional signal available and is inverted into Sure's convention instead of being passed through. Scoped to TRANSFER specifically: CASH_TYPES is unreferenced, so every non-trade type reaches this method and broadening the else branch would silently flip SPLIT, MERGER, JOURNAL and others. Fixes #2756 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-25 18:54:37 +02:00
kianrafieeandClaude Fable 5	40b18e8484	feat(reports): add net worth chart with breakdown tooltip (#2716) ... * Add monthly net worth chart with group breakdown to Reports Adds a net worth trend chart to the Reports > Net Worth section, rendered in the same design scheme as the dashboard chart. The chart shows one data point per month across the period selected at the top of the Reports page, and its hover tooltip breaks the hovered month down into per-account-group balances (Cash, Investments, Credit Cards, Loans, etc.) under Assets and Liabilities headings with section totals. - BalanceSheet::NetWorthBreakdownSeriesBuilder builds the monthly series by running Balance::ChartSeriesBuilder per account group (grouped by accountable type), with liabilities reported as positive magnitudes and all-zero groups omitted; cached with the same invalidation pattern as the existing net worth series - net_worth_chart Stimulus controller extends the existing time_series_chart controller, overriding only data normalization and the tooltip template - Reports controller passes the series through the existing net_worth_metrics hash; tooltip headings reuse existing locale keys Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address review: month-over-month tooltip deltas, Stimulus value labels - Recompute each chart point's trend from the previous monthly point instead of inheriting the raw series trend, which at a monthly interval compared the underlying balance row's own start/end and so reflected only the last balance update before the sample date (chatgpt-codex-connector). The first point has no prior month and renders the standard flat state. - Pass tooltip section labels to the Stimulus controller as declared values (data-*-value attributes) per coding guidelines (coderabbit) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 05:59:32 +02:00
Guillem Arias Fauste	9d4b4bc27c	feat(jobs): reap imports and exports stuck by lost background jobs (#2681) ... * feat(jobs): reap imports and exports stuck by lost background jobs A hard-killed worker (OOM, SIGKILL during deploy) loses its in-flight Sidekiq job permanently. Sync is the only model with a stale sweep; everything else wedges in a non-terminal status forever: - Import stuck "importing"/"reverting" (e.g. #2274) - ImportSession stuck "importing" — unrecoverable, publish_later refuses to re-publish while importing - FamilyExport stuck "pending"/"processing" — exports index polls every 3s indefinitely - PdfImport's AI-processing claim held forever (ProcessPdfJob's reclaim only runs if the job is redelivered) - Provider activities_fetch_pending flags stranded when a self-rescheduling fetch chain loses a link SyncCleanerJob (existing hourly cron) now sweeps all of them, each isolated so one failure doesn't block the rest, and records every reaped record as a DebugLogEntry with the family attached. Idempotency guards so a stray or redelivered job cannot corrupt a record the reaper (or a user retry) has since moved on: - Import#publish skips complete/reverting/revert_failed imports — a redelivered ImportJob after completion double-applies data for import types without row dedup. Failed imports deliberately stay publishable: their transaction rolled back, so a re-run is a retry. - FamilyDataExportJob refuses terminal exports but still allows processing ones through, since graceful-shutdown redelivery is what completes them. Reaper thresholds (6h imports, 2h exports) key off updated_at and dwarf legitimate runtimes, so live jobs are not swept in practice. * fix(jobs): make the reapers race-safe and commit-aware Review feedback on #2681 (jjmata, Codex, CodeRabbit): - Every sweep now mutates under record.with_lock with a staleness re-check, mirroring the guard Sync#perform gained in #2680 — a job finishing between the sweep query and the write can no longer be clobbered mid-flight - Import.clean distinguishes which side of import!'s single transaction the worker died on: rows attached means the data committed and only the status write was lost, so the record is finalized as complete (marking it failed invited a re-publish that double-imports types without row dedup, e.g. TradeImport); no rows means a clean rollback and the failed/try-again path stays - PdfImport.clean applies the same split: no rows → the AI-extraction claim died, reclaim to pending; rows → the publish died post-commit, finalize complete instead of letting the same extracted rows be published twice. Stuck PdfImport reverts (previously unswept by either clean) now go to revert_failed like every other import - ImportSession.clean reconciles chunks whose import! committed but never got the complete-status write before failing the session, so re-publish skips them instead of duplicating their rows via SureImport's split path - Import#publish redelivery skip is captured via DebugLogEntry instead of Rails.logger so support can see it in /settings/debug - The interrupted-error copy is i18n-backed (imports.errors.interrupted) * fix(jobs): round-2 review feedback on the reapers - Import.clean excludes session-owned chunks (import_session_id: nil) — SyncCleanerJob runs it before ImportSession.clean, so it could finalize or fail a SureImport chunk outside the session flow that owns its lifecycle. Regression test added (CodeRabbit major) - family.sync_later moved outside the row-lock transaction in both reap paths — Rails doesn't defer enqueues to after-commit by default, so Sidekiq could pick the job up before the status write was visible - Per-record rescue in Import.clean / PdfImport.clean so one bad record doesn't abort the rest of the hourly sweep - ImportSession.clean uses the importing? enum predicate; reconcile_committed_chunks! iterates with each (default-ordered association made find_each warn, and chunk counts are tiny) * fix(jobs): address round-3 reaper review (isolation + commit signal) Per-record rescue isolation for the three sweeps that lacked it — FamilyExport.clean, ImportSession.clean, and SyncCleanerJob's activity-flag loop — mirroring Import.clean/PdfImport.clean. One bad record (validation error, DB blip) no longer aborts the rest of that sweep for the hour; the activity-flag guard is per-record so a failure also stops skipping the models that follow. data_committed? now covers Category/Rule/Merchant imports, whose records hang off the family rather than the import (no entries or accounts), via the new Import#committed_by_named_records? helper. A committed one is reaped to complete instead of a retryable failed; nameless RuleImport rows carry no stable key, so a nameless-only file has no commit signal and stays retryable. * fix(schema): drop duplicate enable_banking_accounts columns from merge The merge of main into this branch re-appended product, credit_limit, and identification_hashes after updated_at, so schema.rb declared each twice and db:schema:load raised "you can't define an already defined column 'product'". Removed the duplicate declarations (kept the new treat_balance_as_available_credit column); the test database loads again.	2026-07-25 05:04:30 +02:00
3 people	e3a7107271	Feature/dashboard Add "Money In / Out" dashboard widget with monthly bar chart (#2594) ... * Add "Money In / Out" dashboard widget Adds a new dashboard section showing a monthly bar chart of cash activity alongside a summary card (net balance, income, expenses), with per-widget month navigation and account filtering. - IncomeStatement#totals_for computes income/expense totals for an arbitrary period, optionally scoped to a set of account ids - New bar_chart_controller.js (D3) renders the monthly bars - Income/expense rows link through to filtered transactions Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Fix tooltip/dropdown positioning and split money flow chart by income/expense The widget's @container wrapper established a new containing block for position:fixed descendants, so the month-picker and account-filter menus (floating-ui, strategy: fixed) and the D3 tooltip (container- relative coordinates) rendered away from their trigger/bar. Drop @container in favor of regular viewport breakpoints for this full-width widget, and position the tooltip with page-relative coordinates like the other chart controllers. Also replace the single combined bar per month with a grouped expense/income pair (red/green, with a legend) so each month's inflow and outflow are visible independently. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Cap and scroll the money flow widget's month picker Add an optional max_height to DS::Menu (opt-in, backward compatible) so a long item list scrolls inside a fixed-height panel instead of overflowing the viewport. Use it for the money flow widget's 12-month picker. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Use design system tokens for income/expense indicators in money flow widget Swap the four bg-green-500/bg-red-500 dot indicators (legend + income/expense row links) in the money flow widget for bg-success/bg-destructive, matching the "functional tokens only" rule. The same partial already uses text-success/text-destructive for the balance figure, and bg-success/ bg-destructive are already established elsewhere (DS::Alert, budget_categories/_budget_category.html.erb). * Fix future-month 500 and pending-transaction link mismatch in money flow widget Two CI review findings on the money flow widget: - A future month passed via ?money_flow_month= (e.g. a bookmarked/hand-edited URL) made end_date earlier than month_start once capped at Date.current, which Period.custom rejects, causing a 500. money_flow_month_param now clamps future months to the current month, same as it already does for malformed input. - The income/expense row links passed type/date/account filters but no status, so Transaction::Search included pending transactions even though the displayed totals (IncomeStatement#totals_for) exclude them via excluding_pending. Add status: ["confirmed"] to both links so the linked list matches the card total. Also strengthens the widget's controller tests: asserts the highlighted bar's actual income/expense values instead of just its presence, and adds a regression test proving an account id outside the current user's accessible accounts is dropped (falls back to the unfiltered state) rather than leaking or erroring. * Fix account filter eligibility and SVG dark mode fill in money flow widget Two more CI review findings on the money flow widget: The account filter iterated over all visible/accessible accounts, a broader set than IncomeStatement actually counts (accounts excluded from reports, tax-advantaged accounts like 401k/IRA, or shared accounts not included in the user's finances). Selecting one of these silently computed to zero while its drill-down link could still list its transactions. Add IncomeStatement#eligible_accounts, mirroring the same criteria already applied in the totals SQL, and use it for both the checkbox list and the account_ids intersection. The D3 axis tick text elements used text-primary/text-secondary, which set CSS color, not SVG fill, so labels rendered with the default black fill and were unreadable in dark mode. Add fill-current, matching the pattern already used in sankey_chart_controller.js. Adds controller/model tests for eligible_accounts (excluded from the account filter, ignored when passed as a filter id, excluded from totals) and verifies the dark-mode fill fix visually. * Extract duplicated bar-chart JSON parsing into a test helper The css_select("[data-controller='bar-chart']").first + JSON.parse(chart["data-bar-chart-data-value"]) pattern was repeated across four money flow widget tests in pages_controller_test.rb. Extract it into a private money_flow_bars helper and use it everywhere instead. * Preserve eligible account scope in money flow drill-down links when unfiltered The income/expense drill-down links used money_flow_data[:account_ids] directly, which is nil in the widget's default unfiltered state, so .compact dropped the account filter entirely from the link. TransactionsController treats an absent account_ids as all accessible accounts, a broader set than IncomeStatement#eligible_accounts (which excludes tax-advantaged, excluded-from-reports, and non-finance shared accounts). Users with any such account could click a displayed total and see transactions that were never counted in it. Use selected_account_ids (already computed as money_flow_data[:account_ids] || accounts.map(&:id)) for both links instead, so they always pin to the same eligible accounts backing the total, filtered or not. Left the month-picker link on money_flow_data[:account_ids] so navigating months while unfiltered doesn't bloat the URL with every eligible account id. Adds a regression test confirming the default (unfiltered) links include account_ids and exclude an ineligible account's id. * Refine Money In/Out dashboard widget - 6-month window (was 3), half-width default with responsive stack, income-first bars, 2px floor + faded in-progress (partial) month - Expense series/figures neutral (gray/text-primary) — app reserves red for negative/overspend; neutral zero balance - Account filter: outline DS::Button + list-filter icon trigger with in-panel search (DS::SearchInput + list-filter), matching the app's filter convention - i18n search_accounts (en + fr); bump money_flow bar-count test 3 -> 6 * Clarify Money In/Out scope: month label, 6-month caption, filter "All" Addresses confusion between the widget's own month picker and the dashboard's global period, and between the picked month and the 6-month chart span. - Card now headed with the selected month (e.g. "July 2026") so it's clear the totals below are that month's, driven by the picker - Chart legend row captioned "Last N months" so the trailing window is explicit - Info tooltip by the month picker: the widget scopes to the month you pick here, independent of the dashboard's top-level period - Account filter trigger reads "All accounts" when nothing is filtered out, instead of "Filter accounts (N)" - i18n (en + fr) for the new strings * Match tooltip expense dot to the gray bar palette --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Guillem Arias <accounts@gariasf.com>	2026-07-25 04:59:29 +02:00
jdcdpandjdcdp	849578a84a	Add support for trading212 integration in investments sync (#2513) ... * Add support for trading212 integration in investments sync * Respect Trading 212 history rate limits * Replace hex colors with design tokens * Changed withdrawal to withdraw * Address PR review feedback for Trading 212 integration - Replace all Rails.logger calls with DebugLogEntry.capture across syncer, importer, processor, provider, controller, and unlinking - Fix destroy action to surface unlink errors via DebugLogEntry - Replace hardcoded 'GBP' currency fallback with Current.family.currency - Replace hardcoded English status strings in Syncer with i18n - Add config/initializers/trading212.rb with DEBUG_RAW ENV toggle - Add comprehensive test coverage: item, account, data_helpers, holdings_processor, activities_processor, importer, syncer, and controller tests - Rewrite syncer and controller tests to match actual interfaces * Fix tests and bugs found during local test execution - Fix standard_ticker: empty string caused nil.upcase via [].first - Fix parse_date: DateTime < Date, so when Date caught DateTime first - Fix ActivitiesProcessor/HoldingsProcessor: missing instruments_map in DataHelpers caused NameError when processing dividends - Fix test: security fixture ticker collision with test data - Fix test: sync_status_summary i18n matching in assertions - Fix test: trading212_provider ConfigurationError test path - Fix test: controller invalid params needs Turbo-Frame header - Fix test: syncer test uses stubs instead of strict expects 116 tests, 257 assertions, 0 failures, 0 errors * Keep raw provider response bodies out of exception messages. * Fix Secrets leak into page HTML, prevents the API key/secret from appearing in the HTML source while keeping the "leave blank to keep existing" UX. * Address review findings: env gate, sync test, uniqueness test, destroy flow - Gate TRADING212_DEBUG_RAW behind Rails.env.local? so staging/production cannot accidentally enable raw payload logging - Assert SyncJob enqueue in sync controller test, not just redirect - Fix cross-item uniqueness test to actually use two different items - Remove rescue in destroy so unlink failures stop the flow (matching Brex/Akahu pattern) instead of proceeding to destroy_later silently * Add Trading212 tables to db/schema.rb for CI test database CI runs db:test:prepare which loads db/schema.rb, not migrations. Without these table definitions, fixture loading fails with PG::UndefinedTable: relation "trading212_accounts" does not exist. * Removed lint complaint * Register Trading212 in ProviderConnectionStatus::PROVIDERS Fixes CI failure: test_provider_registry_covers_syncable_family_provider_item_associations * Fixed bad merge --------- Signed-off-by: jdcdp <47483528+jdcdp@users.noreply.github.com> Co-authored-by: jdcdp <jdcdp@cdm4.net>	2026-07-25 04:54:30 +02:00
kianrafieeandClaude Opus 4.8	d267288a45	Add RentCast & Realie integration for automatic property data and valuations (#2727) ... * Add RentCast and Realie AVM providers for property valuation Adds Automated Valuation Model (AVM) provider support so self-hosted users can create property accounts from a US address lookup instead of entering details manually: - Provider::Rentcast and Provider::Realie clients, each fetching the property record (type, year built, square footage) and value estimate in a single API request, registered under a new :property_valuations registry concept - API key fields (encrypted, ENV-overridable) with monthly usage display in Settings > Self-Hosting under "Property Valuation Providers" - New property flow: when a provider key is configured, the method selector offers "Add via RentCast/Realie" alongside manual entry; the lookup form reuses the manual flow's localized address fields and creates the account active with fetched attributes, valuation as balance, and the address saved - SyncPropertyValuationsJob refreshes linked property valuations once a day (never hourly) via config/schedule.yml; each provider enforces its monthly request cap (RentCast 50, Realie 25) with a calendar-month counter shared between creation lookups and refreshes Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Allow ENV override of AVM provider monthly request caps The RentCast (50/month) and Realie (25/month) budgets default to the free tier limits but can now be raised for paid plans via RENTCAST_MAX_REQUESTS_PER_MONTH / REALIE_MAX_REQUESTS_PER_MONTH, mirroring the AlphaVantage and Tiingo request limit overrides. The settings descriptions and usage display reflect the effective cap. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address review feedback: durable request counters, safer refresh job - Move monthly AVM request counters from Rails.cache to a new provider_request_counts table with atomic upsert increments, so the hard budget caps survive cache eviction, restarts, and Redis flushes - SyncPropertyValuationsJob: only mark a property synced when the balance update succeeds (wrapped in a transaction), process stalest valuations first so a tight budget goes where it matters, and report failures via DebugLogEntry.capture instead of Rails.logger - Realie: reject lookups whose returned city/ZIP contradict the entered address (street+state queries can match the wrong city); document that numeric use codes are unpublished and leave the subtype unset - Add Faraday open/request timeouts to both provider clients - Localize all user-facing provider error messages (config/locales/models/provider/en.yml) - Add a check constraint restricting properties.avm_provider to known providers - Use the min-h-80 scale token instead of min-h-[320px] - Tests: exact-argument expectations on the lookup stub, provider stubs in the no-provider test, RentCast/Realie API key update tests, ProviderRequestCount unit tests, failed-balance regression test Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Stub AVM provider registry lookups in settings system test Settings::HostingsController#show now resolves the RentCast and Realie providers for usage display; the system test's partial get_provider stubbing treats the new lookups as unexpected invocations without these. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address second-round review: candidate scan, provider reuse, shared row partial - Realie: when the address lookup returns multiple candidates, pick the first one consistent with the entered city/ZIP instead of judging only the first array element; the location-mismatch error now only fires when no candidate matches - SyncPropertyValuationsJob: resolve one provider instance per key for the whole run, so the per-instance request throttle actually spaces requests across properties instead of resetting on each iteration - Extract the AVM method selector row into a shared partial so the manual and provider options render one shape Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Add retry middleware and sync index from review feedback - Both AVM clients now retry transient connection failures (same Faraday retry config as Tiingo) so a network blip doesn't burn one of the tight monthly budget's requests - Partial index on properties(avm_provider, avm_last_synced_on) backing the daily sync job's filter and stalest-first ordering Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Key the AVM sync index on avm_last_synced_on The daily job orders by avm_last_synced_on ASC NULLS FIRST across all AVM-linked properties, so leading the partial index with avm_provider prevented it from serving the sort. Rekeyed on avm_last_synced_on with matching null ordering; the partial predicate still covers the filter. Amended in place since the migration is unmerged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Map Realie numeric use codes; skip incomplete addresses in sync job - Realie documents its numeric use codes at docs.realie.ai/api-reference/feature-key (earlier skip reason was wrong — the table exists). Map the residential/land/agricultural codes to Property subtypes, leaving codes without a subtype equivalent (e.g. 1006 mobile/manufactured) unset like the RentCast mapping. - The daily job now skips properties whose address is missing a street or state before resolving a provider, logging a warn-level DebugLogEntry, so a malformed address can't burn a monthly-budget request every day. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Guard currency mismatches in refresh; reset AVM keys in test teardown - The daily job now skips (with a warn-level DebugLogEntry) properties whose account currency no longer matches the provider's valuation currency, checked via the concept's valuation_currency before spending a request — writing a USD valuation into a re-currencied account would corrupt the balance - Hostings controller test teardown now clears rentcast_api_key and realie_api_key alongside the other cached global settings Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Validate AVM lookup inputs before spending a provider request The form marks name and address fields required, but a forged or JS-less submission bypasses that and would burn one of the tight monthly-budget requests on a lookup that can't produce a property. Property::AvmImport now validates name and the full address locally (localized error) before calling the provider. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Add preview-and-confirm step to the AVM property lookup RentCast's AVM endpoint is location-based: a plausible but nonexistent address still geocodes and returns an area-derived estimate with no property record behind it. Instead of silently creating an account from that, the lookup now shows what the provider returned — type, year built, area (each "Unknown" when missing), and the estimated value — with an explicit notice when no property record was found, and only the user's confirmation creates the account. The confirm step reuses the fetched data via the form (sanitized server-side), so the flow still costs exactly one provider request. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Require a complete US address before daily valuation refresh The job's guard only required street and state, but a later-blanked city or ZIP silently disables the Realie wrong-city check (blank entered fields count as "no mismatch"), so a refresh could accept another property's valuation. The guard now mirrors the import-time completeness check and also skips addresses edited to a non-US country. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Sign the AVM preview payload; blur valuation in privacy mode - The confirm step now rebuilds everything from a signed, 1-hour message-verifier token generated at lookup time, proving the lookup (and its counted provider request) actually ran — a direct confirm POST with fabricated data can no longer create provider-linked properties that the daily refresh job would then spend quota on. Forged/expired tokens re-render the lookup form with a clear error. - The preview's market value now carries the privacy-sensitive class so privacy mode blurs it like other account amounts. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Treat zero Realie valuations as absent; bind preview token to family Review follow-ups from PR #2727: - Realie returns modelValue: 0 when it can't produce an AVM estimate; zero now falls back to the assessed market value instead of syncing a $0 balance, and an all-zero record errors out. - Monetary values now parse via BigDecimal(value.to_s) rather than Float#to_d, avoiding binary float rounding artifacts in balances. - The signed AVM preview token's purpose is scoped to the family that ran the lookup, so a leaked token can't be replayed cross-family. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Refresh AVM property valuations monthly instead of daily Per @jjmata's review on #2727: valuations change slowly and providers enforce tight monthly request caps, so a daily cron adds no value. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 04:47:58 +02:00
William Wei MingandCursor	f210d1ca4c	Perf/accounts controller index optimization (#1926) ... * fix Prism issue - assigned but unused variable plaid_item * measurement to improve accounts_controller__index performance based on skylight * fix FEEDBACK - Stop eager-loading full sync histories on accounts index * fix FEEDBACK - Remove sticky memoization from SimplefinItem#accounts * fix lint error in PR review * fix FEEDBACK - Avoid returning map misses as authoritative results * fix test error * fix FEEDBACK - Avoid redundant query by using already-loaded @manual_accounts * Address maintainer review on accounts index sync preloading Memoize SimplefinItem#accounts, align syncing? with Sync#visible?, and add fallback regression tests. * Add composite index for sync DISTINCT ON queries Support latest_by_syncable ordering with syncable_type, syncable_id, created_at DESC, and id DESC. * fix error in dockerfile.preview file * Suppress Pipelock false positives on CI database fixtures. Pipelock 2.7.0 full-repo audit flags ephemeral postgres:// URLs in workflow env blocks. Re-apply inline suppressions lost in the main merge. * Address review: guard partial Current sync maps and drop unrelated diff Add key? checks so partially populated Current sync maps fall back to DB queries. Revert Dockerfile.preview and pipelock.yml changes unrelated to the accounts index N+1 optimization. * fix(sync): fully populate Current sync maps for all preloaded syncables * fix(ci): skip scheduled preview cleanup on forks Only run the hourly Cloudflare preview cleanup on we-promise/sure, where the required secrets exist. * Remove schema.rb Postgres-version churn, keep only new syncs index Reset db/schema.rb to upstream/main and re-add only the index_syncs_on_syncable_and_created_at_and_id index. The prior diff included ~30 lines of noise (check-constraint reformatting, virtual column reformat, and column reorderings) caused by dumping under a different PostgreSQL version, which obscured the single intended schema change and invited merge conflicts. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-07-25 03:35:35 +02:00
Max BarbareandClaude Sonnet 5	51c93649da	feat(snaptrade): replace device-flow OAuth with authorization-code + PKCE flow (#2747) ... * feat(snaptrade): replace device-flow OAuth with authorization-code + PKCE flow Squashed from 16 commits on snaptrade-oauth-apps for a clean rebase onto current upstream/main ahead of opening a PR. * fix(snaptrade): address PR #2747 review feedback on OAuth PKCE flow - Remove unreachable dead-code guard in import_latest_snaptrade_data - Guard apply_oauth_tokens! against a malformed payload missing access_token - Wrap token endpoint network errors in ApiError and retry like data calls - Remove unused Provider::Snaptrade#revoke_token! instance method - Preserve return_to/accountable_type through the SnapTrade portal callback so the account-linking flow no longer drops users back to accounts_path - Show the real absolute OAuth callback URL in self-hosted setup instructions - Refresh brakeman.ignore fingerprint for the connect redirect after the return_to/accountable_type params were added Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y8SCCmKX6RphB5E73WSUQQ * fix(snaptrade): don't retry non-idempotent OAuth/API requests CodeRabbit flagged that Provider::Snaptrade retried OAuth token exchanges/refreshes and all API POST/DELETE calls (get_connection_url, delete_connection) after timeouts/connection failures. If the response is lost after SnapTrade already consumed a single-use auth code, rotated the refresh token, or applied a POST/DELETE, replaying the request either fails with invalid_grant on a token that actually succeeded, or risks duplicate side effects. Retries are now limited to GET requests; OAuth token requests and non-GET API calls translate a network failure straight into an ApiError without replay. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NrrGkgSBEqhjjBmmH1fcXL * fix(snaptrade): stop querying non-deterministically encrypted token via empty-string compare CodeRabbit flagged that the syncable scope's where.not(oauth_access_token: [nil, ""]) re-encrypts "" with a random IV on every query, so the "" comparison can never match a stored ciphertext and is a silent no-op. No code path ever persists oauth_access_token as "" (only nil or a real token via apply_oauth_tokens!), so the exclusion is unnecessary -- narrowed the scope to a plain NULL check, which encryption handles transparently since nil is never encrypted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NrrGkgSBEqhjjBmmH1fcXL --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-24 22:45:44 +02:00
Juan José Mata	c6eb7cdeed	Revert "Refactor application workflows and update test coverage" ... This reverts commit 565e049f89.	2026-07-23 13:39:46 -07:00