After D12336:

I reordered these elements in D21200. See also D20967.

The real root cause of this issue may have been a locale setting which uses comma as a decimal separator, see T7339.

@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).

One minor issue with this is that there's some duplication when the commit Fixes Txxx and the associated revision already has the edge (which is very common if the commit Fixes Txxx, because the revision almost always also Fixes Txxx):

I just wanted to hold it across the release cut, it's headed to master shortly.

@epriestley what's blocking landing this diff?

Sounds good. It felt slightly odd to me at first, too, but I think I also got used to it.

It wasn't a major UI issue to start with and yes, you get used to it. I would ignore.

The empty space means "this is a normal commit with no special audit state", and the column collapses if no commits have issues (see this task for an example). That seems fairly reasonable to me?

T13463 is approximately the same as this, but now ripe; I'm going to merge this there.

I don't currently plan to pursue this.

Layout looks very neat but a strange too with that big space gap between the icon on each row and the actual text in this case:

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

Argh, big thanks. Indeed that was not obvious at all to me.

Leaving the "Assign To: [...]" field blank will remove assignees, but this is not obvious:

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 ;)

Probably a good idea, but not worth keeping a task around for.

This is probably a natural feature if we iterate here, but not worth keeping a task around for.

We have no customer interest in this and no current plans to pursue it.

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.

(I'm not 100% sure that D19972 fixes this completely, but it appeared to locally. In the future, "Mail Stamps" should include this information in a more reliable format, although they do not currently include transaction information. See T13069.)

These are actually removed in 2018 Week 33. See T13186 for a small amount of followup and discussion, although there isn't too much new information beyond what's here.

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.

Hey we actually have the same issue-- folks on the team would like to edit "owning team" from within the action menu. The problem with having to edit the task is that the UI for task editing is less discoverable and requires more clicks than the action menu -- folks are used to being able to accomplish what they need from the action menu so it frustrates them when they can't. This isn't a blocking impediment to our workflows or anything but it would be a nice-to-have UI improvement.

The build itself can do this over Conduit. Although it's possible we'll support things like this some day, I think this is currently too niche and disconnected from other application behavior to pursue in the upstream.

Another option could be to only allow lowercase letters in the json specification, with some kind of warning message

Workboards have offered access to multiple task creation forms for some time.

I don't currently plan to do this. At a bare minimum, T5474 may moot it.