Page MenuHomePhabricator

Provide a transaction-level view of feed
Open, NormalPublic

Description

See PHI1261. An install is interested in a more granular version of Feed which can serve in a more audit-focused, less human-focused role.

For example, the ability to query "Show changes to all Herald rules between Jan 1 2019 and Apr 1 2019".

Although this use case is somewhat specialized, this is generally reasonable and likely not difficult to implement. I think the primary difficulties are:

  1. transactions are spread across many tables in many applications;
  2. there is no obvious global order to transactions for pagination;
  3. transactions in general have no way to render a standalone, context-free title like "alice flipped switch X on object Y".

We can likely just accept that this page will be a little slow to resolve (1). We can also provide (or, in an extreme case, require) filtering by object type to resolve this indirectly.

For (2), we can order by <dateCreated, PHID>. This is slightly unorthodox but PHID is a unique field which is technically sortable. The ordering is meaningless/random, but we just need a consistent global ordering, not a global ordering with rich meaning.

For (3), we can render some extra information explicitly to provide context, and lean on Conduit support in some cases.

I anticipate providing this as a more advanced interface in Feed, e.g. Feed → Detailed Transaction Logs or something, and enabling data export to serve "save an audit record" cases more narrowly.

Event Timeline

epriestley triaged this task as Normal priority.May 20 2019, 1:03 PM
epriestley created this task.

Per D20533, the major query this UI uses is currently unkeyed (no dateCreated key on transaction tables).

It may be a good idea to add this key. Pros: page gets faster, probably much faster. Cons: fairly heavy migration for every install -- probably not "hours", but probably more than "minutes".

On this install, the default page takes 4s to generate, which is tolerable. I don't expect this page to see heavy use.

Since the immediate motivation is primarily a specific issue (PHI1261) I'm inclined to see if it fills the role for that install without a migration. If it's unusably slow or timing out I'll likely add the key.

The actual change to add the key is ~1 line since all the affected tables use the same schema definition, but since it's a key managed by bin/storage we can't (easily) make it optional or make the migration an online migration.