[GH-ISSUE #8000] [Feature] Preserve original bank import memo separately from editable notes #117638

Closed
opened 2026-06-11 13:04:17 -05:00 by GiteaMirror · 3 comments
Owner

Originally created by @hexsprite on GitHub (May 30, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/8000

Verified feature request does not already exist?

  • I have searched and found no existing issue

Pitch: what problem are you trying to solve?

When transactions import via bank sync (SimpleFin/GoCardless) or file import, the bank's memo/description lands in the transaction Notes field. Notes is the only free-text field, and it's the one I use for my own annotations ("split with Alex", "reimburse from work", etc.).

The two purposes collide. The moment I edit Notes to add my own context, the original bank memo is overwritten and lost from view. I can't keep the bank's description and add my own note — they share one box.

This mirrors a problem Actual already solved for payees: imported_payee preserves the original bank payee read-only, while the editable payee is mine. Notes has no equivalent twin, so imported memo and user notes can't coexist.

(Worth noting: the full original payload is already retained in the raw_synced_data column on each transaction — the memo isn't truly gone, just never surfaced in the UI.)

Describe your ideal solution to this problem

Mirror the existing imported_payee pattern for notes:

  1. Add an imported_notes field to transactions (parallel to imported_description/imported_payee).
  2. On import, write the bank memo to imported_notes and leave notes for the user — gated by the existing per-account "import notes" preference so current behavior stays available.
  3. Surface imported_notes read-only in the transaction detail view, next to the editable Notes field — same as how imported payee is displayed today.

Alternative ideas worth discussing:

  • Backfill imported_notes from existing raw_synced_data for already-imported transactions.
  • A display toggle for whether the imported memo shows inline in the register vs. only in detail.

Teaching and learning

  • The read-only imported memo should look visually distinct from editable Notes (greyed/labeled "Imported"), reusing the imported-payee UI treatment users already recognize.
  • Docs: add a short note under transaction import explaining that the bank memo is preserved separately and Notes is yours to edit.
  • Potential trip-up: users with the "import notes" preference on today expect the memo in Notes. Migration should preserve their current experience by default; the split behavior could be opt-in initially.
Originally created by @hexsprite on GitHub (May 30, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/8000 ### Verified feature request does not already exist? - [x] I have searched and found no existing issue ### Pitch: what problem are you trying to solve? When transactions import via bank sync (SimpleFin/GoCardless) or file import, the bank's memo/description lands in the transaction **Notes** field. Notes is the only free-text field, and it's the one I use for my own annotations ("split with Alex", "reimburse from work", etc.). The two purposes collide. The moment I edit Notes to add my own context, the original bank memo is overwritten and lost from view. I can't keep the bank's description *and* add my own note — they share one box. This mirrors a problem Actual already solved for payees: `imported_payee` preserves the original bank payee read-only, while the editable `payee` is mine. Notes has no equivalent twin, so imported memo and user notes can't coexist. (Worth noting: the full original payload is already retained in the `raw_synced_data` column on each transaction — the memo isn't truly gone, just never surfaced in the UI.) ### Describe your ideal solution to this problem Mirror the existing `imported_payee` pattern for notes: 1. Add an `imported_notes` field to transactions (parallel to `imported_description`/`imported_payee`). 2. On import, write the bank memo to `imported_notes` and leave `notes` for the user — gated by the existing per-account "import notes" preference so current behavior stays available. 3. Surface `imported_notes` read-only in the transaction detail view, next to the editable Notes field — same as how imported payee is displayed today. Alternative ideas worth discussing: - Backfill `imported_notes` from existing `raw_synced_data` for already-imported transactions. - A display toggle for whether the imported memo shows inline in the register vs. only in detail. ### Teaching and learning - The read-only imported memo should look visually distinct from editable Notes (greyed/labeled "Imported"), reusing the imported-payee UI treatment users already recognize. - Docs: add a short note under transaction import explaining that the bank memo is preserved separately and Notes is yours to edit. - Potential trip-up: users with the "import notes" preference on today expect the memo in Notes. Migration should preserve their current experience by default; the split behavior could be opt-in initially.
GiteaMirror added the featureneeds votes labels 2026-06-11 13:04:17 -05:00
Author
Owner

@coderabbitai[bot] commented on GitHub (May 30, 2026):

⚠️ Possible Duplicate Issue(s)

📝 Issue Planner

Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.

  • Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

<!-- gh-comment-id:4585039494 --> @coderabbitai[bot] commented on GitHub (May 30, 2026): <!-- This is an auto-generated issue plan by CodeRabbit --> <details> <summary>⚠️ Possible Duplicate Issue(s)</summary> - https://github.com/actualbudget/actual/issues/6913 </details> --- <details> <summary>📝 Issue Planner</summary> <sub>Check the box below or use the `@coderabbitai plan` command to generate an implementation plan and prompts that you can use with your favorite coding assistant.</sub> - [ ] <!-- {"checkboxId": "8d4f2b9c-3e1a-4f7c-a9b2-d5e8f1c4a7b9"} --> Create Plan </details> --- <details> <summary> 🧪 Issue enrichment is currently in open beta.</summary> You can configure auto-planning by selecting labels in the issue_enrichment configuration. To disable automatic issue enrichment, add the following to your `.coderabbit.yaml`: ```yaml issue_enrichment: auto_enrich: enabled: false ``` </details> 💬 Have feedback or questions? Drop into our [discord](https://discord.gg/coderabbit)!
Author
Owner

@github-actions[bot] commented on GitHub (May 30, 2026):

Thanks for sharing your idea!

This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don't forget to upvote the top comment with 👍!

<!-- gh-comment-id:4585043832 --> @github-actions[bot] commented on GitHub (May 30, 2026): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don't forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
Author
Owner

@hexsprite commented on GitHub (May 30, 2026):

Duplicate of #6913, which predates this and is already in the needs votes backlog. Closing in favor of that one — folks interested should upvote the top comment there.

<!-- gh-comment-id:4585046471 --> @hexsprite commented on GitHub (May 30, 2026): Duplicate of #6913, which predates this and is already in the `needs votes` backlog. Closing in favor of that one — folks interested should upvote the top comment there.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#117638