Archive into a dated folder #198

New Issue

Closed

opened 2026-09-02 05:06:30 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-02 05:06:30 +00:00

Owner

Archiving put everything in one folder. An Archive that has been collecting for years is a single flat list with no way to narrow it except search.

What it does

Archive by year and Archive by month file into Archive/2026 and Archive/2026/09, creating the folders as needed and reusing them afterwards — including folders made by hand or by another client, which is the usual way Archive/2026 already exists.

Decisions worth reviewing

Numeric, zero-padded names rather than month names. These are real server-side mailboxes, not anything of ihasmail's. Every other client sees them, so a folder created as "September" by someone reading in English stays "September" for the same account read in Japanese — the name is stored, not translated. And 09 sorts between 08 and 10; "September" sorts between "October" and nothing useful.

The date is read in the reader's own timezone, not UTC. It has to agree with the date shown against the message in the list. A message that arrived 00:30 UTC on 1 September is dated 31 August in New York, and filing it under 09 while the list says August would be the app disagreeing with itself.

A selection spanning two months is two destinations. The moves are made silently and one toast names where everything went — the folder where there is a single answer, the count where there is not. Each group raising its own toast with its own Undo would mean undoing a third of a move. One Undo restores the whole selection to wherever each message came from, captured before anything moves.

The menu names the destination where there is one, so it reads "Archive to 2026/09" rather than describing the rule, and falls back to "Archive by month" only when the selection has no single answer.

A message whose date cannot be read goes to Archive itself, rather than a folder named after a guess.

Testing

20 new unit tests — 10 on the date/grouping logic and 10 on the store against a simulated server, covering folder creation, reuse of existing folders, a month folder nesting inside a year folder created moments earlier, a selection splitting across two months, the single-toast behaviour, and the no-Archive-folder case.

Suite green: web 623, server 110, typecheck clean.

Not verified in the app

The store behaviour is covered by the tests above, but I could not get the list's right-click menu to open under browser automation this run (it opened fine earlier in the day with the same approach), so the two new menu labels have not been seen rendered. The label logic is four lines over the same tested helpers, but it is worth a click before merge.

Merged 2026-09-01 as coffey-labs/ihasmail@3c3ffbd425

_{Rebuilt from: git history, session transcript.}

Archiving put everything in one folder. An Archive that has been collecting for years is a single flat list with no way to narrow it except search. ## What it does **Archive by year** and **Archive by month** file into `Archive/2026` and `Archive/2026/09`, creating the folders as needed and reusing them afterwards — including folders made by hand or by another client, which is the usual way `Archive/2026` already exists. ## Decisions worth reviewing **Numeric, zero-padded names rather than month names.** These are real server-side mailboxes, not anything of ihasmail's. Every other client sees them, so a folder created as "September" by someone reading in English stays "September" for the same account read in Japanese — the name is stored, not translated. And `09` sorts between `08` and `10`; "September" sorts between "October" and nothing useful. **The date is read in the reader's own timezone, not UTC.** It has to agree with the date shown against the message in the list. A message that arrived 00:30 UTC on 1 September is dated 31 August in New York, and filing it under `09` while the list says August would be the app disagreeing with itself. **A selection spanning two months is two destinations.** The moves are made silently and one toast names where everything went — the folder where there is a single answer, the count where there is not. Each group raising its own toast with its own Undo would mean undoing a third of a move. One Undo restores the whole selection to wherever each message came from, captured before anything moves. **The menu names the destination where there is one**, so it reads "Archive to 2026/09" rather than describing the rule, and falls back to "Archive by month" only when the selection has no single answer. **A message whose date cannot be read** goes to Archive itself, rather than a folder named after a guess. ## Testing 20 new unit tests — 10 on the date/grouping logic and 10 on the store against a simulated server, covering folder creation, reuse of existing folders, a month folder nesting inside a year folder created moments earlier, a selection splitting across two months, the single-toast behaviour, and the no-Archive-folder case. Suite green: web 623, server 110, typecheck clean. ## Not verified in the app The store behaviour is covered by the tests above, but I could not get the list's right-click menu to open under browser automation this run (it opened fine earlier in the day with the same approach), so **the two new menu labels have not been seen rendered**. The label logic is four lines over the same tested helpers, but it is worth a click before merge. **Merged** 2026-09-01 as coffey-labs/ihasmail@3c3ffbd425dd <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#198