| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An absent view record read as unread, so on first sign-in every thread a list
had ever carried was unread. On a busy list that is thousands of threads the
user never intended to read, inflating the Home dashboard, the needs-attention
snapshot, and the widget with a number that means nothing.
Record a baseline when an account is activated: mail that predates it is read,
mail after it is not. activate() is the single funnel for launch validation,
account switching, and adding an account, so one call covers every sign-in path.
Accounts that already carry read state have been in use, so they get a
distantPast baseline and keep every unread thread they had — upgrading must not
silently mark a real backlog as read.
markUnread now records an explicit distantPast marker instead of deleting the
entry. Deleting would drop the thread back to the baseline rule, so marking an
old thread unread would appear to do nothing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InboxThreadSummary.id returned threadGroupingKey, which is listRID plus the
subject with Re:/Fwd: stripped. Two unrelated threads on one list sharing a
subject therefore shared an id — common on sourcehut, where "[PATCH] test" is
an ordinary subject — which collides under Identifiable in every list that
renders these summaries.
Key id on the root Message-ID, which is unique per thread, and leave
threadGroupingKey subject-based so replies still collapse into one
conversation.
Read state moves to threadGroupingKey at each call site. It was already
keyed on that string via id, so persisted keys are unchanged and marking a
conversation read still covers the whole subject group, matching how
HomeViewModel already builds the key for isUnread.
|
