Take the filing action, not the whole rule #39

Closed
opened 2026-08-25 19:23:48 +00:00 by jcoffey-dev · 0 comments
Owner

This should have been part of #37 and missed the merge. You asked for it, I committed it three minutes after #37 was already merged, and it went to a branch whose PR was closed. Main is currently running the behaviour you rejected — dropRulesForFolders, which deletes the entire rule.

John spotted the gap; I had reported CI passing on "the updated PR" when the change was never in it. My mistake, twice over: pushing to a merged branch, and reporting a check result without confirming what it covered.

What it changes

Deleting a folder currently removes every rule that filed into it, along with whatever else those rules did — a rule that filed into Work, marked read and stopped processing lost the marking and the stopping too. Deleting a folder says nothing about whether those were still wanted.

detachFolders() removes only the fileinto aimed at the deleted folder. A rule left with no actions at all is still removed, since it has nothing to do, and a rule filing into two folders keeps the one that still exists. The toast distinguishes the two outcomes.

Verified

In the running app, two rules aimed at the same folder:

rule actions before after deleting the folder
Only files fileinto Newsletters removed
Files and marks read fileinto Newsletters, markread kept, markread only

The script stored on the server agrees — the survivor reads "actions":[{"type":"markread"}].

12 tests over this module: the filing-only rule, the rule with other actions, a subtree delete where one survives and one does not, a rule with a second fileinto pointing elsewhere, and path-only matching. npm run typecheck, npm test — 213 web + 88 server passing.

🤖 Generated with Claude Code

Merged 2026-08-25 as coffey-labs/ihasmail@99382486b8

Rebuilt from: git history, session transcript.

**This should have been part of #37 and missed the merge.** You asked for it, I committed it three minutes after #37 was already merged, and it went to a branch whose PR was closed. Main is currently running the behaviour you rejected — `dropRulesForFolders`, which deletes the entire rule. John spotted the gap; I had reported CI passing on "the updated PR" when the change was never in it. My mistake, twice over: pushing to a merged branch, and reporting a check result without confirming what it covered. ## What it changes Deleting a folder currently removes every rule that filed into it, along with whatever else those rules did — a rule that filed into Work, marked read and stopped processing lost the marking and the stopping too. Deleting a folder says nothing about whether those were still wanted. `detachFolders()` removes only the `fileinto` aimed at the deleted folder. A rule left with no actions at all is still removed, since it has nothing to do, and a rule filing into two folders keeps the one that still exists. The toast distinguishes the two outcomes. ## Verified In the running app, two rules aimed at the same folder: | rule | actions before | after deleting the folder | | --- | --- | --- | | Only files | `fileinto Newsletters` | removed | | Files and marks read | `fileinto Newsletters`, `markread` | kept, `markread` only | The script stored on the server agrees — the survivor reads `"actions":[{"type":"markread"}]`. 12 tests over this module: the filing-only rule, the rule with other actions, a subtree delete where one survives and one does not, a rule with a second `fileinto` pointing elsewhere, and path-only matching. `npm run typecheck`, `npm test` — 213 web + 88 server passing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) **Merged** 2026-08-25 as coffey-labs/ihasmail@99382486b853 <sub>Rebuilt from: git history, session transcript.</sub>
This repo is archived. You cannot comment on issues.