[jfrench9]

Summary

The inbox now reads the open-item suggestion the API puts on a bank line that pays an open bill or invoice exactly. Before this, such a line showed as having no suggestion, and approving it with the suggested account posted to payables or receivables without settling the item.

Changes

• Inbox list (ledger/inbox/content.tsx, lib/ledger/suggestions.ts): an "Open item" badge and filter; these lines can be ticked for a batch approve like any other suggested line.
• Line detail (ledger/inbox/EventBlockDetailModal.tsx):
  • Approving or classifying with the suggested account takes the suggestion, so the bill or invoice is settled. "Remember" is not offered for it.
  • Choosing another account shows an "A separate transaction" box. Approve and Classify ask for it before sending, and send not_a_settlement when it is ticked.
  • A bill or invoice the reviewer picks by hand still wins, as before.

Deploy Notes

Needs RoboSystems API v1.22.3 or later, which adds the open-item suggestion and refuses another account for such a line without not_a_settlement. Against an older API the change is inert: no line carries the suggestion.

Testing

• npm run test: 1,231 passed across 135 files. Format check, lint and typecheck clean.
• New tests: taking the suggested account sends accept_suggestion; another account is held until the box is ticked, then sends not_a_settlement.
• Not run: npm run build, and no browser check against a live API.

🤖 Generated with Claude Code

[github-actions]

Change classification: normal — platform or application code changed.

A normal change carries a documented automated review on this pull request before merge, in place of a second human approver. The change-classification job requests that review and passes once it has been posted. Recorded by the change-classification job.

[jfrench9]

@claude please review this PR

[claude]

Claude finished @jfrench9's task in 20s —— View job

---

Review: open-item suggestion in the inbox

Verdict: looks good. One small nit, a few non-blocking questions.

I read the full diff and the surrounding modal and list code. I did not run the tests or the build.

What works

• open_item is added consistently to the type, label, colour, type guard and filter options in suggestions.ts and content.tsx.
• matchesOpenItem excludes splits and hand-picked settlements, and takesOpenItem / passesOverOpenItem split the two cases cleanly. A hand-picked bill still wins, as the description says.
• Suppressing "Remember" via !takesOpenItem is correct. setSeparateTransaction(false) is reset on both an event change and an account change, so a stale tick can't leak to another account.
• classificationPatch is also spread into the preview request (~line 393), so preview carries accept_suggestion / not_a_settlement too. That is consistent with what Approve sends.
• The batch approve already works for these lines. isSelectable accepts any non-null source, so no change was needed there.
• Both new tests cover the intended paths: accept sends accept_suggestion, and another account is held until the box is ticked, then sends not_a_settlement.

Nit

• EventBlockDetailModal.tsx ~line 102: SEPARATE_WORD_NEEDED was inserted between the /** Bank-feed lines that post from an account choice… */ doc comment and CLASSIFIABLE_EVENT_TYPES. The comment now sits above the wrong constant. Move the new constant above that comment.

Non-blocking questions

• Untested edge cases. There are no tests for the needsSeparateWord guard on the Classify button, or for the list filter and badge. The Classify path is a separate useCallback with its own guard, so one small test would protect it.
• Stale suggestion on re-classify. When prior (classified_element_id) is already set, classifiedElementId starts from it rather than the suggestion. A previously classified, not-yet-approved line whose prior account differs from the suggestion will show the "separate transaction" box on open. That is probably the intended behaviour, but it is worth confirming.
• Older API. The PR notes the change is inert before v1.22.3. If a v1.22.3 server rejects accept_suggestion on a line that is no longer an open-item match, friendlyError in @/lib/ledger/errors may not map that error. Check that the new server errors (not_a_settlement required, suggestion no longer applicable) have friendly messages there, per the CLAUDE.md convention.
• Build. The PR says npm run build and a live-API check were not run. That is reasonable given the API dependency, but a quick manual check against v1.22.3 before release would be worthwhile.