Page MenuHomePhabricator

Rebuild Diffusion/Audit on top of CustomField infrastructure
Closed, WontfixPublic

Description

Introduced primarily by T1703, the new CustomField infrastructure provides a better approach to implementing custom fields than previous efforts in Maniphest, Differential and Releeph do. Particular improvements are:

  • We no longer need "Selectors", and fields can autoload.
  • Everything is web-UI configurable with nice controls.
  • Support for indexes.
  • Support for ApplicationSearch.
  • Support for ApplicationTransactions.

The three implementations we should migrate are:

  • Releeph, partially converted already and covered in T3718.
  • Maniphest
  • Differential

Maniphest and Differential are likely to be involved.

Differential and Releeph are likely to require significant coordination with Facebook.

Revisions and Commits

Related Objects

Event Timeline

epriestley triaged this task as Normal priority.Sep 4 2013, 3:31 PM
epriestley added a project: Custom Fields.
epriestley added subscribers: epriestley, btrahan, Unknown Object (MLST).
epriestley edited this Maniphest Task.
epriestley renamed this task from Rebuild all custom fields on top of CustomField infrastructure to Rebuild Diffusion/Audit on top of CustomField infrastructure.May 24 2014, 1:01 PM
epriestley added a project: Diffusion.

Retargeting this since I think everything else is essentially done.

Will this allow me to add my own custom fields to differential? I would very much like to have a bugid & project field (I'm using a third party bugdb)

Yes. You can see the plans for Custom Fields in the documentation here, in the tables near the top of the page:

https://secure.phabricator.com/book/phabricator/article/custom_fields/

chad changed the visibility from "All Users" to "Public (No Login Required)".Jul 3 2015, 5:22 AM
eadler added a project: Restricted Project.Apr 7 2016, 6:04 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 7 2016, 6:05 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 8 2016, 6:41 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 1 2016, 10:39 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 6 2016, 4:10 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:00 PM
epriestley claimed this task.

I'm going to close this as "Wontfix". Although adding custom fields is something we may still do, I no longer expect to "rebuild" on top of that infrastructure.

This task was filed shortly after CustomFields were written when it looked like we might move all object fields onto that infrastructure, but their design ultimately evolved in a different direction, largely into EditEngine. Comparatively, CustomFields are more monolitic (one field definition controls all behavior) while EditEngine is more flexible (a larger number of smaller pieces are composed to create overall behavior). CustomFields were the first major step in this direction, but EditEngine and supporting infrastructure, like ModularTransactions, ultimately feel like they are better fits to the problem space.

Diffusion now (mostly) uses EditEngine, per T10978, so we effectively skipped a rebuild on custom fields.

We could still add custom fields to Diffusion, but the use cases aren't terribly clear and this task doesn't meed the modern standard for describing root problems. In particular:

  • This task mentions "Projects", but they've been supported for some time.
  • This task mentions "Bug ID", but the scope of that isn't clear. It seems unlikely that an actual custom field is the best fit.
  • We haven't, as far as I know, seen other specific interest in adding other mutable fields to commits.
  • In cases where the goal is just to parse information out of commits, an integration with Differential fields alongside T9713 probably makes more sense.

If you have a use case which you believe might be addressed by this, please file a new feature request following Contributing Feature Requests and we can figure out how to tackle it.

As I've understood the EditEngine supersedes CustomFields by the flexibility. Are there any examples (in code or in documentation) on how new fields can be added to commits or other entities?

For company I'm working at the use case would be references from other websites to this commit. Later this can be used to search for referenced commits only.

epriestley closed subtask Restricted Maniphest Task as Wontfix.Jun 28 2017, 5:06 PM