misleading error message when no archive folder is set yet #217

New Issue

Closed

opened 2026-09-02 15:00:46 +00:00 by unknown · 2 comments

unknown commented

2026-09-02 15:00:46 +00:00

The original description was not recovered.

Referenced by commits

coffey-labs/ihasmail@5e6e049eef 2026-09-02 Set the Archive role from ihasmail, rather than describing it
coffey-labs/ihasmail@1611ae6918 2026-09-02 Say the Archive folder needs the role, not the name

_{Rebuilt from: session transcript. Opening date is approximate.}

*The original description was not recovered.* **Referenced by commits** - coffey-labs/ihasmail@5e6e049eef9d 2026-09-02 Set the Archive role from ihasmail, rather than describing it - coffey-labs/ihasmail@1611ae69180d 2026-09-02 Say the Archive folder needs the role, not the name <sub>Rebuilt from: session transcript. Opening date is approximate.</sub>

jcoffey-dev commented

2026-09-02 15:12:02 +00:00

Owner

Fixed in #220, live now as 2026.9.2+pr220. You're right, and it was worse than imprecise — it was a loop with no way out.

The lookup is by special-use role and by nothing else, so a folder called "Archive" with no role never satisfies it. Which means the old message told you to do a thing that could not work, and then said the same thing again once you'd done it. Compounding it: ihasmail has no way to assign a role either. Folders settings shows a folder's role next to it and offers no control to change it, so there was nothing the message could have been asking you to do inside ihasmail at all.

It now says what is actually required, and where it lives:

No Archive folder is set. A folder needs the Archive role on the server; naming it "Archive" is not enough.

Worth knowing: an All Mail folder satisfies it too — the lookup falls back to the all role before giving up. The message doesn't say so, because a toast that lists both roles is a worse toast, and the archive role is the one people are actually looking for.

A question you're better placed to answer than I am, since you run an instance per client. JMAP allows role on Mailbox/set, but I don't know whether Stalwart honours it — I haven't put it to a live server, and I'd rather not build on the assumption. If it does, the better fix is a "make this the Archive folder" control in Folders settings, and this message stops needing to exist. If Stalwart refuses it, the message stays the right answer and the role stays a server-side matter. Do you know offhand, or is it worth me probing?

All nine translations carry the correction rather than falling back to English. They're mine rather than a native speaker's, like the rest of the catalogue — if any of your German-speaking colleagues wants to tell me the phrasing is clumsy, I'd welcome it.

Fixed in #220, live now as `2026.9.2+pr220`. You're right, and it was worse than imprecise — it was a loop with no way out. The lookup is by special-use role and by nothing else, so a folder called "Archive" with no role never satisfies it. Which means the old message told you to do a thing that could not work, and then said the same thing again once you'd done it. Compounding it: ihasmail has no way to *assign* a role either. Folders settings shows a folder's role next to it and offers no control to change it, so there was nothing the message could have been asking you to do inside ihasmail at all. It now says what is actually required, and where it lives: > No Archive folder is set. A folder needs the Archive role on the server; naming it "Archive" is not enough. Worth knowing: an **All Mail** folder satisfies it too — the lookup falls back to the `all` role before giving up. The message doesn't say so, because a toast that lists both roles is a worse toast, and the archive role is the one people are actually looking for. A question you're better placed to answer than I am, since you run an instance per client. JMAP allows `role` on `Mailbox/set`, but I don't know whether Stalwart honours it — I haven't put it to a live server, and I'd rather not build on the assumption. If it does, the better fix is a "make this the Archive folder" control in Folders settings, and this message stops needing to exist. If Stalwart refuses it, the message stays the right answer and the role stays a server-side matter. Do you know offhand, or is it worth me probing? All nine translations carry the correction rather than falling back to English. They're mine rather than a native speaker's, like the rest of the catalogue — if any of your German-speaking colleagues wants to tell me the phrasing is clumsy, I'd welcome it.

jcoffey-dev commented

2026-09-02 15:42:14 +00:00

Owner

Follow-up, and I can answer my own question: yes, Stalwart takes it.

I asked above whether Mailbox/set honours role, since I hadn't put it to a live server and didn't want to build on a guess. I have now. Setting role: "archive" on a folder that carried none returned updated, the read-back showed the role, and archiving worked immediately afterwards — as an ordinary user through ihasmail's own proxy, no admin API, on 0.16.20. Stalwart's source agrees: SpecialUse::parse accepts "archive", a role belongs to exactly one folder, and Inbox/Junk/Trash refuse to move theirs.

Which makes the message I shipped yesterday the wrong answer to your report. It was accurate and useless: it told you the role lives on the server and left you nothing to do about it inside ihasmail. The right answer was to set the role.

So, in #221, live now as 2026.9.2+pr221:

The toast does the work. "No Archive folder is set yet." now carries a Create one action that makes the folder and finishes the archiving that failed — you don't reselect the messages.

A folder already named Archive with no role is adopted, not duplicated. That is precisely the state you reported from: right name, no role, archiving blind to it. One click and it becomes the Archive you already made. Matched regardless of case or stray spaces. If a folder called Archive turns out to be your Sent folder, it's left alone — taking its role to fix archiving would break sending.

Folders settings has a Role column. Archive, Drafts and Sent can be set; Inbox, Junk and Trash show theirs and are locked, because your server refuses to move those. A role another folder already holds is left out of the list rather than offered and refused, so moving one is a deliberate two steps with no error to decipher.

One deliberate limit: the folder is created with the name Archive, not a translated one — the same reason renaming writes back the server's own name. A German session creating "Archiv" that an English one can't find would be a worse bug than the one this fixes.

Thanks for the report. It was a two-line message that turned out to be hiding a missing feature.

Follow-up, and I can answer my own question: **yes, Stalwart takes it.** I asked above whether `Mailbox/set` honours `role`, since I hadn't put it to a live server and didn't want to build on a guess. I have now. Setting `role: "archive"` on a folder that carried none returned `updated`, the read-back showed the role, and archiving worked immediately afterwards — as an ordinary user through ihasmail's own proxy, no admin API, on 0.16.20. Stalwart's source agrees: `SpecialUse::parse` accepts `"archive"`, a role belongs to exactly one folder, and Inbox/Junk/Trash refuse to move theirs. Which makes the message I shipped yesterday the wrong answer to your report. It was accurate and useless: it told you the role lives on the server and left you nothing to do about it inside ihasmail. The right answer was to set the role. So, in #221, live now as `2026.9.2+pr221`: **The toast does the work.** "No Archive folder is set yet." now carries a **Create one** action that makes the folder *and finishes the archiving that failed* — you don't reselect the messages. **A folder already named Archive with no role is adopted, not duplicated.** That is precisely the state you reported from: right name, no role, archiving blind to it. One click and it becomes the Archive you already made. Matched regardless of case or stray spaces. If a folder called Archive turns out to be your Sent folder, it's left alone — taking its role to fix archiving would break sending. **Folders settings has a Role column.** Archive, Drafts and Sent can be set; Inbox, Junk and Trash show theirs and are locked, because your server refuses to move those. A role another folder already holds is left out of the list rather than offered and refused, so moving one is a deliberate two steps with no error to decipher. One deliberate limit: the folder is created with the name `Archive`, not a translated one — the same reason renaming writes back the server's own name. A German session creating "Archiv" that an English one can't find would be a worse bug than the one this fixes. Thanks for the report. It was a two-line message that turned out to be hiding a missing feature.

This repo is archived. You cannot comment on issues.

2 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

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