fix: judge a conversation's trash state on all of its messages

Item 178. everySelectedRowIsInATrashFolder() read
ThreadSummary::firstMessagePath for any row that was not a message row.
That was correct while a thread row MEANT that message (item 108) and
stopped being correct when item 177 made it mean the conversation. A
conversation is in the trash only when ALL of its messages are, so a
partly trashed thread answered on whichever message the query returned
first: Delete could be hidden on a conversation that still had mail
outside the trash, and Restore offered on one that mostly did not.

Not data-affecting. Both actions are no-ops in the wrong direction:
Delete on already-trashed mail takes moveMessages()' already-there
branch, and Restore on mail that was never trashed finds nothing to
move.

qtmaildir cannot produce such a thread itself, since Delete is absent on
a reply row and Restore is thread-scoped. Two things outside it can:
another client trashing a single message, and a reply arriving after the
conversation was trashed.

ThreadDigest already walks every message of the selected conversation
for its sender counts, and a filename is served from the index like
everything else in it, so the paths ride along on a request the
selection already makes rather than costing a walk on every query.
ThreadDigest::messagePaths is relative to the mail root, for the reason
firstMessagePath records: an absolute path matches no account and
silently resolves every row to none. MainWindow keeps them beside the
dashboard's thread id and clears them when the dashboard is left, so a
late digest cannot answer about another row.

One limit, stated in the code rather than hidden. The digest is
requested only for a single selected conversation row, so that is the
only case with a real answer; any other selection falls back to the
summary's one path. That fallback IS the pre-177 answer and is wrong in
exactly the same partial case, which is the point: a multi-row selection
is left no worse than it was, rather than given a second, differently
wrong rule of its own. Making it exhaustive costs a per-query walk over
every message, which is what this avoids.

Two tests, both mutation-checked. The worker test puts its two messages
in different folders, since two in one folder answer identically
whichever way the code resolves them. The window test asserts both
directions, so a fix that simply hid Delete everywhere would fail it,
and sets totalCount explicitly: a summary left at the default is a
message row, and the test would otherwise exercise the other branch and
pass for the wrong reason.

Suite: 42 of 43, with undoMovesTheMessageBack failing as it does on
master (item 136).

1 files changed, 29 insertions, 0 deletions

diff --git a/src/mainwindow.h b/src/mainwindow.h
index 16bf8c4..d7579f4 100644
--- a/src/mainwindow.h
+++ b/src/mainwindow.h
@@ -202,6 +202,16 @@ public:
     /// command was pushed, which is what "this did nothing" has to assert.
     int undoDepthForTesting() const { return m_undoStack.count(); }
 
+    /// Item 178. Stands in for the digest round trip, which a bare window has
+    /// no worker to make. Sets what onThreadDigestLoaded() would have set.
+    void setConversationPathsForTesting(const QString &threadId,
+                                        const QStringList &paths)
+    {
+        m_conversationPathsThreadId = threadId;
+        m_conversationPaths = paths;
+        refreshTrashActions();
+    }
+
     /// Runs a purge without the confirmation, which a test cannot drive: a
     /// modal blocks the thread it is shown on (item 84). What this exists to
     /// cover is what happens AFTER the user confirms.
@@ -1640,6 +1650,25 @@ private:
     /// which is also set for a thread of one message that renders normally.
     QString m_dashboardThreadId;
 
+    /// Every message path of the conversation the dashboard is showing, keyed
+    /// by its thread id so a late digest cannot answer about another row.
+    ///
+    /// Item 178. Delete and Restore ask whether a row is in the trash, and a
+    /// conversation is in the trash only when ALL of its messages are; the
+    /// summary carries ONE path, which was the right answer while a thread row
+    /// meant its first message (item 108) and stopped being right when item
+    /// 177 made it mean the conversation.
+    ///
+    /// Filled from ThreadDigest, which the selection already requests and
+    /// which already walks every message, so this costs no query of its own.
+    /// It is therefore known only for a SINGLE selected conversation row, and
+    /// everySelectedRowIsInATrashFolder() falls back to the summary's one path
+    /// when it is absent: the fallback is the pre-177 answer, wrong in exactly
+    /// the same partial case, so a multi-row selection is no better than
+    /// before and no worse.
+    QString m_conversationPathsThreadId;
+    QStringList m_conversationPaths;
+
     /// The message a dashboard entry asked for and the thread it is in, both
     /// empty when nothing is waiting. See selectMessageInCurrentThread().
     QString m_dashboardSelectMessageId;