Fix an issue where handles could load with the incorrect viewer when building…


Fix an issue where handles could load with the incorrect viewer when building mail about changes to related objects

See https://phabricator.wikimedia.org/T179591. Some time ago, all handle rendering preloaded handles: things emitted a list of PHIDs they'd need handles for, then later used only those PHIDs.

Later, we introduced HandlePool and lazy/on-demand handle loading. Modern transactions mostly use this to render object PHIDs.

When we build mail, many newer transactions use an on-demand load to fetch handles to render transactions. This on-demand load may use the original viewer (the acting user) instead of the correct viewer (the mail recipient): we fetch and reset handles using the correct viewer, but do not overwrite the active viewer for on-demand loading. This could cause mail to leak the titles of related objects to users who don't have permission to see them.

Instead, just reload the transactions with the correct viewer when building mail instead of playing a bunch of setViewer() and clone games. Until we're 100% on modular transactions, several pieces of the stack cache viewer or state information.

Test Plan:

  • Created task A (public) with subtask B (private).
  • Closed subtask B as a user with access to it.
  • Viewed mail sent to subscribers of task A who can not see subtask B.
    • Before change: mail discloses title of subtask B.
    • After change: mail properly labels subtask B as "Restricted Task".

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D20525