There is currently no concept of a "default" account anywhere in the domain model or settings.
The closest existing behavior is in ComposeViewModel.kt (~line 123):
— when compose opens without an explicit account context (e.g. the FAB from the unified inbox,
or a mailto:/share intent with no account hint — see IntentComposeParser), it silently falls
back to available.first(), which is whatever order AccountDao.observeAll() returns
(ORDER BY email, alphabetical — see data/local/dao/AccountDao.kt). That's an incidental
default, not a chosen one. (Note: making LibreMail the OS-level default mail app for mailto:
links is a separate, already-implemented concern — this ticket is about picking a default among
the user's own added accounts.)
Scope
Persist a defaultAccountId: String? preference (SettingsRepository, following the
existing key/AppSettings-field/setter pattern used for other settings there).
Add a "Set as default" affordance — most naturally a row/switch in AccountSettingsScreen.kt
(alongside the existing per-account signature/notification sections), or a radio-style
indicator against each account row in SettingsScreen.kt's account list. Only one account
can be default at a time.
Handle the account being removed while it's the default (clear the preference; falls back to
the incidental available.first() behavior, or pick a new default explicitly — decide during
implementation).
Wire the default into ComposeViewModel's fallback (~line 123): prefer the persisted default
over available.first() when no explicit fromAccountId is supplied.
Decide whether "default account" should also influence anything beyond compose (e.g. which
account's folders the drawer opens to first) — the ticket title only says "default mail
account," so start scoped to the compose from-account; note any broader default-selection
behavior as a follow-up rather than expanding this ticket.
Acceptance criteria
The user can designate one added account as default from Settings.
A new compose started without an explicit account (FAB, mailto: with no account hint) uses the
default account when one is set.
Removing the default account doesn't crash or strand the app in a broken state.
Related to #164 (account reordering) — both add per-account, user-controlled ordering/selection
state that doesn't exist today; consider whether "default" and "first in the reordered list"
should be the same concept or genuinely independent (this ticket treats them as independent unless
decided otherwise).
## Context
There is currently no concept of a "default" account anywhere in the domain model or settings.
The closest existing behavior is in `ComposeViewModel.kt` (~line 123):
```kotlin
val effectiveId = _state.value.fromAccountId ?: available.first().id
```
— when compose opens without an explicit account context (e.g. the FAB from the unified inbox,
or a `mailto:`/share intent with no account hint — see `IntentComposeParser`), it silently falls
back to `available.first()`, which is whatever order `AccountDao.observeAll()` returns
(`ORDER BY email`, alphabetical — see `data/local/dao/AccountDao.kt`). That's an incidental
default, not a chosen one. (Note: making LibreMail the OS-level default mail app for `mailto:`
links is a separate, already-implemented concern — this ticket is about picking a default *among
the user's own added accounts*.)
## Scope
- [ ] Persist a `defaultAccountId: String?` preference (`SettingsRepository`, following the
existing key/`AppSettings`-field/setter pattern used for other settings there).
- [ ] Add a "Set as default" affordance — most naturally a row/switch in `AccountSettingsScreen.kt`
(alongside the existing per-account signature/notification sections), or a radio-style
indicator against each account row in `SettingsScreen.kt`'s account list. Only one account
can be default at a time.
- [ ] Handle the account being removed while it's the default (clear the preference; falls back to
the incidental `available.first()` behavior, or pick a new default explicitly — decide during
implementation).
- [ ] Wire the default into `ComposeViewModel`'s fallback (~line 123): prefer the persisted default
over `available.first()` when no explicit `fromAccountId` is supplied.
- [ ] Decide whether "default account" should also influence anything beyond compose (e.g. which
account's folders the drawer opens to first) — the ticket title only says "default mail
account," so start scoped to the compose from-account; note any broader default-selection
behavior as a follow-up rather than expanding this ticket.
## Acceptance criteria
- The user can designate one added account as default from Settings.
- A new compose started without an explicit account (FAB, mailto: with no account hint) uses the
default account when one is set.
- Removing the default account doesn't crash or strand the app in a broken state.
## Relevant files
- `data/settings/SettingsRepository.kt`, `ui/settings/AccountSettingsScreen.kt`,
`ui/settings/SettingsScreen.kt`, `ui/compose/ComposeViewModel.kt` (~line 123).
## Dependencies
Related to #164 (account reordering) — both add per-account, user-controlled ordering/selection
state that doesn't exist today; consider whether "default" and "first in the reordered list"
should be the same concept or genuinely independent (this ticket treats them as independent unless
decided otherwise).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Context
There is currently no concept of a "default" account anywhere in the domain model or settings.
The closest existing behavior is in
ComposeViewModel.kt(~line 123):— when compose opens without an explicit account context (e.g. the FAB from the unified inbox,
or a
mailto:/share intent with no account hint — seeIntentComposeParser), it silently fallsback to
available.first(), which is whatever orderAccountDao.observeAll()returns(
ORDER BY email, alphabetical — seedata/local/dao/AccountDao.kt). That's an incidentaldefault, not a chosen one. (Note: making LibreMail the OS-level default mail app for
mailto:links is a separate, already-implemented concern — this ticket is about picking a default among
the user's own added accounts.)
Scope
defaultAccountId: String?preference (SettingsRepository, following theexisting key/
AppSettings-field/setter pattern used for other settings there).AccountSettingsScreen.kt(alongside the existing per-account signature/notification sections), or a radio-style
indicator against each account row in
SettingsScreen.kt's account list. Only one accountcan be default at a time.
the incidental
available.first()behavior, or pick a new default explicitly — decide duringimplementation).
ComposeViewModel's fallback (~line 123): prefer the persisted defaultover
available.first()when no explicitfromAccountIdis supplied.account's folders the drawer opens to first) — the ticket title only says "default mail
account," so start scoped to the compose from-account; note any broader default-selection
behavior as a follow-up rather than expanding this ticket.
Acceptance criteria
default account when one is set.
Relevant files
data/settings/SettingsRepository.kt,ui/settings/AccountSettingsScreen.kt,ui/settings/SettingsScreen.kt,ui/compose/ComposeViewModel.kt(~line 123).Dependencies
Related to #164 (account reordering) — both add per-account, user-controlled ordering/selection
state that doesn't exist today; consider whether "default" and "first in the reordered list"
should be the same concept or genuinely independent (this ticket treats them as independent unless
decided otherwise).