[Feature] Keep each PDF import separate under "import data" in settings

[Jonseed]

Description

Currently it combines them by date, so if you import multiple PDFs, it only shows one line under import data, so you can't selectively delete one PDF import. It would be good if these were listed as separate imports. I think manual entries are also combined by date (not sure if those should be combined).

System Info

• Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 Edg/144....
• Screen: 1920x1080
• Theme: dark
• AI Provider: ollama

[elkimek]

I looked into this. The challenge is that entries are keyed by date throughout the app — the data pipeline, manual entry, inline editing, and value deletion all find entries by date. Splitting into separate entries per PDF would risk breaking those lookups (e.g., which entry does a manual edit go to when two entries share a date?). The safer approach would be tracking which markers came from which file, but that's a bigger data model change. With the filename now visible in Settings (#38), you can at least see the source. Keeping this open for a future refactor.

[Jonseed]

If you import two (or more) PDFs on the same date though, they are merged in the same import line in settings, so even the filename listed there doesn't help if it only shows the latest filename imported (it doesn't show all filenames imported). And you can't remove only one PDF if it imported wrong, you have to remove all of them that were imported on that date.

[elkimek]

Improved the visibility side — when multiple PDFs are imported on the same date, the Settings Data tab now shows "2 files" (hover to see all filenames). Previously the latest filename silently overwrote the earlier one.

Separating entries per PDF would require a significant architectural change — the entire data pipeline, manual entry, inline editing, value deletion, and export/import all key on date. Reworking that carries a lot of risk for existing data and would need careful migration. Keeping this open but it's not something I'd rush into.

[elkimek]

This is a structural limitation of v1's data model — entries are merged by date into a single blob, with no provenance tracking for which PDF a value came from.

The v2 architecture (TypeScript/Svelte/Tauri rewrite) normalizes the data model into relational rows. Each lab value gets a source column (filename, import timestamp), which makes selective deletion per-import straightforward. Targeting this as part of the v2 data model redesign.

Leaving this open as a v2 milestone.