Page MenuHomePhabricator

In Herald, save applied transaction PHIDs in the transcript and display them in the UI
ClosedPublic

Authored by epriestley on May 13 2019, 5:02 PM.
Tags
None
Referenced Files
F14372347: D20518.diff
Fri, Dec 20, 7:45 PM
Unknown Object (File)
Mon, Dec 16, 11:57 PM
Unknown Object (File)
Wed, Nov 27, 5:25 PM
Unknown Object (File)
Nov 19 2024, 10:20 PM
Unknown Object (File)
Nov 16 2024, 10:16 AM
Unknown Object (File)
Nov 12 2024, 1:00 AM
Unknown Object (File)
Nov 8 2024, 5:54 AM
Unknown Object (File)
Oct 28 2024, 5:36 PM
Subscribers
None

Details

Summary

Ref T13283. Since D14575, we already pass applied transactions to Herald, but they exist only as a backwards compatibility layer and have no upstream callsites.

Save the applied transaction PHIDs as part of the object transcript, and show them in the UI.

Test Plan
  • Viewed a modern transcript, saw a list of transactions.
  • Viewed an older transcript, saw nothing (since there were no transactions in the transcript).

Screen Shot 2019-05-13 at 9.56.31 AM.png (730×1 px, 174 KB)

Diff Detail

Repository
rP Phabricator
Branch
herald1
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 22803
Build 31281: Run Core Tests
Build 31280: arc lint + arc unit

Event Timeline

amckinley added inline comments.
src/applications/herald/controller/HeraldTranscriptController.php
30

Shouldn't this just be $object = null? I guess it's not really a behavior change since this behavior is new, but it seems weird that I suddenly won't be able to see a Herald transcript if the view policy on the affected objects changes out from under me. Maybe it doesn't matter because no one is looking at old Herald transcripts and they get GC'd anyway.

This revision is now accepted and ready to land.May 15 2019, 5:37 PM

HeraldTranscriptQuery already requires that you must be able to see the object, it just doesn't actually attach it anywhere. Possibly a cleaner fix is to make it do that.

(Although losing access to an older transcript because you lost access to an object is slightly weird, being able to take any object, go find transcripts for it in Herald, and see some of its fields would be super bad and fairly strongly violate policy controls if anyone had written a rule like "task summary matches regexp ..." so the field value was exposed, so I think it's definitely right that we err on the side of locking you out of things.)

  • In HeraldTranscriptQuery, attach the object we load (if the transcript has an object).
  • Later, just getObject() it.

Test plan:

  • Viewed a transcript for an object I can see.
  • Viewed a transcript for an object I can't see, got a policy error.