Skip to content

Feature Groups

Jump to bottom
SkimMail docs edited this page Sep 15, 2026 · 1 revision

English · Tiếng Việt · 中文

Account groups

Since 0.1.3: named, colored/emoji-tagged folders for your accounts, with a handful of settings a group can hand down to its members.

What this solves

Once you have more than a couple of accounts, "all of them in one flat list" stops being organized. Groups let you cluster accounts — work, personal, clients — filter the unified inbox by group, and (for one setting, see below) avoid configuring the same egress on every account in a cluster individually.

Where it is

Settings ▸ Groups. Listing groups is available to every signed-in user (viewer and above); creating, editing, deleting, reordering and resetting groups are operator actions. See Users and roles.

Creating and editing a group

A name (required), a color and an emoji for the sidebar, plus a set of settings the create/edit form calls shared: an egress assignment (proxy, WireGuard tunnel or relay), a sync depth, and a notifications on/off switch. Every field is patched independently — omitting one from a request leaves it unchanged.

What actually inherits from a group, and what only looks like it does

This is the one thing on this page worth reading carefully, because the three "shared" settings above do not behave the same way:

  • Egress is real inheritance. Resolving an account's egress (which proxy, tunnel or relay its IMAP connection actually dials through) checks the account's own assignment first and falls back to its group's if the account has none of its own — a real, server-side join consulted every time an egress plan is resolved: dialing, Test, and the IP shown on the account card. See Connections for the full egress model.
  • Sync depth is not inherited, and does not even affect the group's own accounts. The group's sync_depth_days field is stored and returned to the UI, but the code that actually decides how far back an account syncs reads only that account's own column — it never looks at the account's group at all. Assigning an account to a group does not copy the group's depth onto it either. In practice this field just sits there; see Accounts and Sync and Sync Health for the matching per-account finding.
  • The notifications toggle is stored and never read. A group's on/off switch persists to a notify_policy column, and nothing in the notification-sending code (channel routing, Watchtower alerts, per-account push) ever reads it. It looks like a group-wide mute switch; it is not wired to anything. The control that actually gates notifications is per-account — see Notifications.

Reordering, counts, and reset

  • Reordering groups, and reordering the accounts inside one group, are both drag-and-drop actions saved as a sort_order — display only.
  • The sidebar's group filter shows a live per-group message count alongside each group's name.
  • Reset offers two modes: unassign empties every group (accounts fall back to ungrouped, the groups themselves stay) or delete removes every group outright. Either way, account credentials and cached mail are untouched — only the grouping is affected — and it runs as one transaction, so it is all-or-nothing. Accounts that were inheriting an egress from their group have their pooled IMAP connections invalidated immediately afterward, so the very next dial reflects the account's new (ungrouped) egress instead of quietly continuing to reuse a connection still routed through the old group's proxy.
  • Reset is scoped to your own groups. It used to reset the whole instance regardless of who pressed it — one of the cross-user fixes closed in 1.12.0, see Users and roles.

Deleting a single group

Removes the group only. Its accounts are detached (group_id cleared), never deleted — their credentials and cached mail are completely untouched.

Limits
Available since 0.1.3
Role viewer lists; operator creates/edits/deletes/reorders/resets
Tier limits Community 2 · Sponsor 5 · Pro unlimited — see Plan and license
Real inheritance egress (proxy/tunnel/relay) only
Stored but unused sync depth, the notifications toggle
Ownership groups are per-user (since 1.10.0); egress endpoints themselves stay instance-wide

What it does not do

  • Does not push a sync-depth default down to member accounts. Set each account's depth on the account itself.
  • Does not mute or route notifications for its members. The toggle exists in the UI and the database and nowhere else.
  • Deleting a group never deletes or reconfigures its accounts — it only detaches them.
  • Groups do not carry egress endpoints with them across users. Groups are per-user since 1.10.0, while the proxies/tunnels/relays a group can point at remain instance-wide — worth knowing if you administer a shared, multi-user instance.

See also

SkimMail · skimmail@base101.app · 2026-09-15 · commit dffbb18

Clone this wiki locally