Origin: code review of PR #54 (drawer folder de-duplication).
Problem
resolveDrawerLabels is wired only into FolderDrawer (FolderDrawer.kt:83). Two other surfaces still render the bare folderDisplayLabel:
MoveFolderDialog (MailboxScreen.kt:676) — its folder list is moveTargetFolders = observeFolders(acct) filtered only by selectable + not-current-folder, so both of a same-named pair appear as pixel-identical rows (plain Text, no icons) that move mail to different folders.
App-bar title (MailboxScreen.kt:198) — after tapping "Drafts - Gmail" in the de-duplicated drawer, the title shows plain "Drafts", indistinguishable from the same-named user folder.
The move picker is the one surface where picking the wrong row performs an action, and there is no destination feedback afterward.
Failure scenario
Gmail account with [Gmail]/Drafts (special-use) plus a user folder "Drafts" (both role DRAFTS via name fallback): long-press a message → Move → two identical "Drafts" rows; tapping the wrong one silently files the message into the provider's built-in Drafts (or vice versa).
Suggested fix
resolveDrawerLabels is a pure fullName → label function, so the cheap fix is calling it from the dialog and title too. The deeper fix: resolve labels once per folders emission (ViewModel or domain layer) and let drawer, move picker, and title all consume the same resolved map — the helper's own name ("Drawer") records that a general mechanism was scoped to one surface.
Origin: code review of PR #54 (drawer folder de-duplication).
## Problem
`resolveDrawerLabels` is wired only into `FolderDrawer` (`FolderDrawer.kt:83`). Two other surfaces still render the bare `folderDisplayLabel`:
- **MoveFolderDialog** (`MailboxScreen.kt:676`) — its folder list is `moveTargetFolders = observeFolders(acct)` filtered only by `selectable` + not-current-folder, so both of a same-named pair appear as pixel-identical rows (plain `Text`, no icons) that move mail to *different* folders.
- **App-bar title** (`MailboxScreen.kt:198`) — after tapping "Drafts - Gmail" in the de-duplicated drawer, the title shows plain "Drafts", indistinguishable from the same-named user folder.
The move picker is the one surface where picking the wrong row performs an action, and there is no destination feedback afterward.
## Failure scenario
Gmail account with `[Gmail]/Drafts` (special-use) plus a user folder "Drafts" (both role DRAFTS via name fallback): long-press a message → Move → two identical "Drafts" rows; tapping the wrong one silently files the message into the provider's built-in Drafts (or vice versa).
## Suggested fix
`resolveDrawerLabels` is a pure `fullName → label` function, so the cheap fix is calling it from the dialog and title too. The deeper fix: resolve labels once per `folders` emission (ViewModel or domain layer) and let drawer, move picker, and title all consume the same resolved map — the helper's own name ("Drawer") records that a general mechanism was scoped to one surface.
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.
Origin: code review of PR #54 (drawer folder de-duplication).
Problem
resolveDrawerLabelsis wired only intoFolderDrawer(FolderDrawer.kt:83). Two other surfaces still render the barefolderDisplayLabel:MailboxScreen.kt:676) — its folder list ismoveTargetFolders = observeFolders(acct)filtered only byselectable+ not-current-folder, so both of a same-named pair appear as pixel-identical rows (plainText, no icons) that move mail to different folders.MailboxScreen.kt:198) — after tapping "Drafts - Gmail" in the de-duplicated drawer, the title shows plain "Drafts", indistinguishable from the same-named user folder.The move picker is the one surface where picking the wrong row performs an action, and there is no destination feedback afterward.
Failure scenario
Gmail account with
[Gmail]/Drafts(special-use) plus a user folder "Drafts" (both role DRAFTS via name fallback): long-press a message → Move → two identical "Drafts" rows; tapping the wrong one silently files the message into the provider's built-in Drafts (or vice versa).Suggested fix
resolveDrawerLabelsis a purefullName → labelfunction, so the cheap fix is calling it from the dialog and title too. The deeper fix: resolve labels once perfoldersemission (ViewModel or domain layer) and let drawer, move picker, and title all consume the same resolved map — the helper's own name ("Drawer") records that a general mechanism was scoped to one surface.