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. FeedDetailed 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.