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?

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.

The long-term fix is putting this stuff on EditEngine (some discussion in T11887) but this should be fixable in the short term.

I suspect this might be because the value for "Continue" is an empty string here: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/harbormaster/customfield/HarbormasterBuildStepCoreCustomField.php$27 ; At least, changing that value to be non-empty seems to solve this.

T11864 is another flavor of [ ] Show on commit message template., like T7327, although it wants to hide "Subscribers" instead of show "Projects".

This should now just work without any changes at HEAD of master. Let us know if you're still seeing issues after updating.

I hit this as well - I was able to fix the handful of tasks created before setting "search" -> "true" by just re-saving those tasks.

I built a similar UI as part of D15926, but we declined to actually bring it upstream. It's possible that we may revisit this in the future, or that it may become possible via T418, but I don't currently plan to pursue this.

@epriestley Is there a pathway for reading (not writing) edges which would be open to community contribution? Having arc patch Tnnnn functionality, pulling all the revisions attached to a particular task, would be really attractive for us as we tend to have a larger number of revisions per task.

Phabricator's infrastructure has evolved a lot and CustomFields now serve a smaller role than they once did -- roughly, just custom fields. Later generation stuff (particularly EditEngine) feels better factored, and has reduced the responsibility of CustomFields.

Same here. I've created customfield "Requirement" to identify external Requirement ID. Searching using Contains Words is inadequate cause it search all fields containing similar string.

But the documentation says:

I don't know if it's intentional or not, but I can find tasks with custom field text values using the Contains Words field.

There may be a better pathway forward for issuing the actual prompt after T10329, depending on how that pans out.

Thanks!! its worked now.

In T418#157090, @chad wrote:

What version of pfabricator does the following "shouldAppearInListView and renderOnListItem" parameter is available in ManiphestCustomField ?

Not sure what the context is for this question. This task is open because the feature is not complete.

What version of pfabricator does the following "shouldAppearInListView and renderOnListItem" parameter is available in ManiphestCustomField ?

What version of pfabricator does the following "shouldAppearInListView and renderOnListItem" parameter is available in ManiphestCustomField ?

I believe the use cases here are reasonably solved with EditEngine in Maniphest and new Projects (build your own custom form, hide what you want from Marketing, and provide a link to the form on the Marketing project).

They can now be sorted by custom fields, and after T4863 they'll be able to render in lists. It's possible that T9372 will impact this, too.

Reading Custom Fields is now supported in new *.search endpoints (paste.search, maniphest.search, owners.search).

I removed "Quick Create" entirely in T9905, so this is obsolete (at least, for now).