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:

This is something that is needed every day, e.g. find tickets which are not yet assigned..

It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.

Changing the type is going to run into the issue of what to do about the fields which differ between the two types. Fields which are present in the old type will continue to be displayed unless you clear them when changing types.

Easy changing of a subtype of an existing task would be on my wishlist too. In our worklow it happens fast, that a bug report or a task is tranformed to a story in the next sprint. To edit the subtype in some simple way would greatly help.

How can I change the subtype of an existing task? This only allows me to load tasks into a form specific to their existing subtype. (i.e. I have an animal, I want to edit it and change it into a plant.)

It was a little unclear in the walkthrough you gave on how to use it. Are the field types (animal.type plant.habitat) suppose to be hidden by default on when using a specific subtype (animal.type on plant subtype)?

ok, that was the problem - default values will cause a field to show up in the 'details' section, thanks!

@cos: probably should not have a default value.

ok, so the intent is that any initialized field shows up in details, but no others? If so, then do fields with default values show-up? I have a software version field for example has a default of 0.0.0 and it shows up for subtypes for which it's hidden. Here are some screenshots to show you:

@cos, which specific types of fields are you seeing issues with?

In T12314#217334, @shandor wrote:

The interaction between subtypes and "required" flag was mentioned briefly in the weaknesses section, but it's a little unclear how this new feature will work with them. With Custom Forms, we are currently unable to use Required custom fields properly because they are still required fields even when hidden in some particular forms. Do Task Subtypes solve this issue naturally, or is it something that still needs to be implemented?

The interaction between subtypes and "required" flag was mentioned briefly in the weaknesses section, but it's a little unclear how this new feature will work with them. With Custom Forms, we are currently unable to use Required custom fields properly because they are still required fields even when hidden in some particular forms. Do Task Subtypes solve this issue naturally, or is it something that still needs to be implemented?

I'm now using this and it works well! I've noticed one wrinkle that I don't understand, namely, the 'Details' section when viewing a task includes some custom fields and not others? In particular, it includes custom fields that are hidden for the current task subtype. Is there anyway of controlling what appears here?

@20after4 : Ah. So by default, everyone just gets a "create task" option, which would never use any custom forms or subtypes. That does seem to resolve my concerns (although I still think it would be cool for phab to behave differently depending on which project(s) I was viewing).

@ksmith: Thanks to the new 'favorites' menu, each user can customize their menu, there is no longer a global 'create new' menu, as it's been replaced.

Our phabricator instance (WMF) is shared by many(!) different projects and teams. If I understand the current proposal, all the subtypes and forms would be available to all users across all teams and projects, except where specific access is limited (e.g. security issues). I think that forces us to either: a) have very few subtypes, which manage to achieve consensus, or b) have a lot of subtypes, which would mean that everyone's "create new" menu would be very cluttered.

In T12314#213245, @epriestley wrote:

Weakness: Subtyping is Probably Only Useful in Maniphest

Subtyping is likely to involve a large number of changes in shared infrastructure (EditEngine), but they will probably only ever be useful in Maniphest. Although most applications now use EditEngine, I can't really come up with any good use cases for subtyping in other applications. Perhaps Calendar could use subtyping on events, but this feels like a solution searching for a problem.

A basic version of this is now available in HEAD of master. Here's a walkthrough of what we've implemented and a discussion of some areas where we'd like feedback.

Go ahead and file something separate for that, I don't think it interacts here.

thanks, sounds great!

Great, thanks! I haven't come up with any other major concerns myself after considering this for a couple of days, and expect to move forward shortly.

"Overall, I think this is the model we should continue under, and task subtyping should be implemented in terms of views of a subset of fields."
"In the current model, you choose a task type first, by selecting a "Create" form, not by choosing from a "Type" dropdown within the task. "

Yeah, that's a reasonable starting point. I'm sure noone has 99+ task edit forms..... ⛈

And the pencil icon on workboards, the pencil icon on the list view, and the "Edit Task" action from task detail pages would default to "Edit Plant Task", yeah. The workboard change would only pertain to creating new tasks directly on a workboard.

Right now, this menu always says "Create Task..."

For now, we either don't change workboards or just put all the global options into the menu, probably?

So here's a tentative plan for subtyping:

Custom Forms are the general tool we want to use here, but they currently have some limitations for this use case. As a starting point, here's what they can do today, some of the strengths, and some of the weaknesses.

I don't see how to configure/use that

Neither can I - I may have imagined it being possible to "lock" the edit form of a task to the one that was used to create them...

Great! Glad that worked out. I think the documentation is good enough given it's description. We'll keep an eye on it.

Yes! It worked! Thanks!!!

Does datasource work? I've never tried it personally, but seems to be what you're asking for.
https://secure.phabricator.com/book/phabricator/article/custom_fields/

I don't think the upstream should provide this yet. You're already able to write your own custom field and since it's your code and your rules, will be 10x better for your users. Mostly, we need to abstract out other similar top level problems (input that drives an input?) and devise a single solution that may or may not perfectly fit your needs. It also might take years.