phorge-phorge/resources/sql/patches/20130814.usercustom.sql

CREATE TABLE {$NAMESPACE}_user.user_configuredcustomfieldstorage (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  objectPHID VARCHAR(64) NOT NULL COLLATE utf8_bin,
  fieldIndex CHAR(12) NOT NULL COLLATE utf8_bin,
  fieldValue LONGTEXT NOT NULL,
  UNIQUE KEY (objectPHID, fieldIndex)
) ENGINE=InnoDB, COLLATE utf8_general_ci;
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: PhabricatorCustomFieldList: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. PhabricatorUserConfiguredCustomFieldStorage: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). Configuration-Driven Custom Fields: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). Fixed Some Bugs: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749 2013-08-14 17:10:16 +02:00			`CREATE TABLE {$NAMESPACE}_user.user_configuredcustomfieldstorage (`
			`id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,`
			`objectPHID VARCHAR(64) NOT NULL COLLATE utf8_bin,`
			`fieldIndex CHAR(12) NOT NULL COLLATE utf8_bin,`
			`fieldValue LONGTEXT NOT NULL,`
			`UNIQUE KEY (objectPHID, fieldIndex)`
			`) ENGINE=InnoDB, COLLATE utf8_general_ci;`