I could not find in the documentation how are we supposed to set a value for a custom field of type "user".
In particular, I am looking at doing this: set the default value to the current user (the user creating the Maniphest task)

Just a question - are there any technical reasons why providing custom field for "projects" may not be a good idea?

@epriestley As perhaps an example of another use case, in my workplace we needed, amongst others, the following lists of Maniphest tasks:

1. assigned to the viewer, regardless of the author,
2. authored by the viewer, without self-assigned,
3. subscribed by the viewer, without (1) and (2).

(1) is obviously trivial (there's already a built-in query), but the other two seemed to require custom "NOT" filtering. Of course, (2) can be solved to an extent by using "Group by assigned", but it's not very convenient. Because I tend to self-assign most of the tasks that I create, the ones that I have assigned to other people quickly get visually overwhelmed by the large group of "Assigned to kerberizer" (not to mention that with my username this huge group tends to get in the middle of the list).

This is likely straightforward.

See also PHI1358, which is an actual concrete request for sensible relabeling of "Description" in a subtype.

Trying to preserve markup format in the output is likely a road to mental ruin (Hyperlinking, referencing, bolding, formatting in who knows what export formats). PhabricatorStringExportField should be sufficient.

I wholeheartedly agree that all that proxy field mess needs to go away. With that gone the only moderately confusing part remaining would be the way in which custom fields interact with herald, email and notifications.

(This is likely to be very long, very rambling, and not particularly enlightening or useful.)

Making a way to set fields to default: disabled would make this feature even better ;)

This would be incredibly useful for the things we are trying to do at WMF. I've gone so far as to duplicate lots of forms for each subtype and remove fields as needed. This results in N * N forms and it's not at all manageable beyond a very small number of sub-types.

When we reach getCustomFieldSpecificationForRole($role), via EditEngine, the $this object currently does not have a subtype set, so it can't make any decisions about which fields to expose. This appears to have a fairly surgical fix in EditEngine, but if there are like 10 more of these coming it might merit another look.

These have existed for a while and recently got support for customizing sub-object behaviors in 2018 Week 50 (Mid December) and are being extended to Projects in 2019 Week 5, so it looks like they're here to stay.

PHI781 asks for [ ] Show on commit message template. for "Maniphest Tasks:".

From https://discourse.phabricator-community.org/t/how-to-get-custom-field-of-transactiontype/1532 (and my followup research), there doesn't appear to be a way to extract custom field information using conduit (or Herald Web Hooks).
transaction.search actually lists type as null and no fields.

It would be perfect if the syntax supported in remarkup links could be used, which means that for @swisspol's example, projects/phabricator_transition/ would translate to https://temp.phacility.com/w/projects/phabricator_transition/.
And it would be even more awesome if the behavior of the displayed link in the "view" page could be the same, which means that in this case, it wouldn't display the link but the name of the Phriction page!

I'm rolling this forward into T13049. See also D18919.

I've marked D18879 as fixing this. It does not extend bulk editor support to all custom field types, but makes such support generally trivial. We'll fill in and test more field types as use cases arise.

The best place for this kind of question is now your organization's support pact -- @tammybutow or @alexmv should be able to help you get access.

@epriestley so maybe this isn't the right place to leave this comment (let me know if I should create a new task?) but I'm finding this is acting in a way that seems a bit inconsistent. In particular, I added a new boolean custom field --

I'm going to call this effectively resolved:

Seems better to pursue this as an CustomField extension. https://secure.phabricator.com/book/phabricator/article/custom_fields/

You can find tasks with no owner by searching for "No Owner", like this: