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.

Roughly, the Custom Forms model is that all tasks have all fields. Task/workflow "subtypes" are created by showing users different views of those fields (usually: hiding most of them).

I think these are the major strengths of the current approach:

• All tasks having all fields feels like a good model, particularly in terms of search, API, and integrations with other applications.
• Allowing administrators to control which forms users see feels useful in many situations.
• Having users choose a task type first by choosing a form feels like it simplifies things a bit.

These are the potential weaknesses or limitations:

• There is currently limited support for custom create forms from Workboards, "Create Subtask", etc.
• Tasks don't "remember" which form they were created with.
• There's no concept of a formal "subtype".
• Templating behaviors are hard-coded and not always appropriate.
• There's some interest in restoring the "Copy" / "Create Another" workflows.
• If we add subtypes, we need to think about how changing one subtype into another subtype works and other similar operations.
• If we add subtypes, we need to think about how to distinguish tasks of different subtypes on workboards and project lists.
• Nuance may overlap with some use cases here.
• A future "checklist/test case" tool (Unnamed Manual Test Case Application) may overlap with some use cases here.
• There are probably no other applications which can benefit from subtyping.

Using Custom Forms Today
Documentation: User Guide: Customizing Forms

Today, you can define different create and edit forms with different sets of fields. For example, this install has four forms for creating/editing tasks: "New Bug", "New Feature", "Basic Edit" and "Advanced Edit/Create". The "New Bug" and "New Feature" forms offer a limited set of fields with some prefilled defaults and custom help text. The "Basic Edit" form allows users who file those tasks to edit some basic properties. Members of Community have access to the full power "Advanced" form, which allows you to edit every field.

The documentation above should be reasonably helpful in discussing how to set that up. (Note that there was one minor bug introduced last week which won't promote to stable for an hour or two, T12301.)

I believe that this system generally gets a lot of things right, but the primary use cases we built it to address involved making it easier for users, particularly new/nontechnical users, to complete workflows like task and bug filing successfully. It does a fairly good job of this (about as good as we can reasonably expect, I think), but doesn't currently accommodate some other related use cases, like having multiple different types of tasks.

Strength: All Tasks Have All Fields

In the current model, every task has all of the possible fields under the hood, and we only change which fields we show to the user depending on context. I think this is the correct model. It makes a lot of things much easier, and I don't expect to change this part of the model.

In particular, this makes Search and Conduit API access straightforward: you can search for things using any possible field. If this eventually became overwhelming on search I'd expect to just try to show different views of the available fields, but I think many search operations want to find tasks regardless of type (e.g., open tasks created by a particular author, or all tasks in a particular project). Conduit access is inherently technical and it isn't a problem to have a large number of fields exposed there. And most other system integrations want to treat all task types the same way (e.g., Txxx mentions, news feed, "Edit Related Tasks", Workboards, Herald, and so on.)

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.

Strength: Policies on Forms/Views

In the current model, it's easy to control who sees which forms This is useful for open source installs and installs with less-technical users because it allows administrators to put guard rails on workflows to help users who are having trouble to succeed. Although this isn't universally useful across all installs (for example, a 6-person startup where pretty much everyone is writing code may not have much use for it) we've benefitted from it ourselves and seen open source installs and installs with more diverse userbases make good use of it. The current implementation generally feels pretty good to me.

We also drive the "Actions" dropdown on comments from the edit form (you can only take actions when commenting that you could also take by editing the form), and this feels pretty natural.

Strength: Choose a Type/Form First

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. I think this is generally a better model:

• Custom Forms support prefilling multi-valued fields like "Tags" and "Subscribers", and giving users a modal choice lets "Bug" vs "Feature" prefill those fields with different values for different task types. If you selected from a dropdown, users could do confusing things like: add some values to "Subscribers", then change the task type. There is no unambiguous way to deal with this case. While this wouldn't be the end of the world, it's simpler and unambiguous if they make a choice at the beginning.
• Custom Forms support a wide variety of other HTTP prefilling options, and it's simpler to create a "New Feature Request" workflow from some other first-party tool if you have a stable link you can rely on.
• Custom Forms support instructions, which are useful when adding guard rails to workflows. They'd be less useful if they changed after you selected a "Type" partway down the form.
• We don't have to worry about writing a bunch of spooky Javascript magic.
• Customizing and previewing forms is more straightforward for administrators.

Weakness: No Custom Create Forms on Workboards or Create Subtask
Related Tasks: T11580, T6064, T10946 (maybe), probably others

Currently, there's no way to choose a specific task subtype when you create a task through "Create Subtask" in Maniphest, or "Create Task..." from a Workboard column. Instead, you get the default "Edit" field that you have permission to access.

We should figure out how (or, possibly, "if") to support subtypes on these workflows. I think the major questions are:

• How do we do this without making the UIs very heavy? For example, T6064 bemoans the current need to click twice to create a task on a workboard. T11481 was unhappy that you had to click even once. If "Create Task..." leads to a form choice, it might require three clicks.
• Do we support some form of per-Workboard form selection? T11580 focuses on certain defaults per-workboard, and a general extension of this is potentially allowing a workboard to have custom forms or subtypes.
• For "Create Subtask", should the available forms depend on the parent task?

Additionally, T5474 may interact here, since column actions would presumably trigger immediately if you created a task into a workboard column. That might be a different (but more complex?) way to accomplish some of these goals.

The simplest implementation here is just to put all of the "Create" forms under both "Create Subtask" and "Create Task" on Workboards. However, this adds a lot of junk to the UI and doesn't give us much power on workboard customization.

This isn't critical to resolve. The simplest step forward is probably:

• Leave "Create Subtask" as-is, since users don't seem to care terribly much and you can always use a top-level create form and then link the tasks up.
• Make Workboards offer all the global create forms in their menus (same number of clicks, just a bigger menu).

Weakness: Tasks Don't Remember Which Form They Were Created With

This is probably the most immediate problem with trying to use Custom Forms to support subtyping: when you create a task with a "New Bug" form, it doesn't "remember" which form you used. When you go to edit it, you get a generic, viewer-dependent form. For Custom Forms to be useful for subtyping, you need to be able to "Edit" a bug and get an "Edit Bug" form, and "Edit" a feature and get an "Edit Feature" form.

In the case where Custom Forms are being used to simplify workflows, this is actually desirable: we want basic users to get a basic edit form and advanced users to get an advanced edit form. And advanced users should probably always have a way to edit all the fields of a task so they can fix unusual problems, although this doesn't necessarily need to be super easy to access.

But in the case of real subtyping -- "New Plant" vs "New Animal" -- the current workflow is that advanced users see a lot of meaningless fields and we lose the subtype workflow.

Fixing this probably involves something like this:

• When you create a task with a specific form, that form has an option to either directly save which form you used, or maybe to set some other kind of "subtype" attribute (like "plant" or "animal"), on the task you create.
• When you edit a task, we use the same form or an appropriate edit form for the subtype, so a "New Plant" task gets edited with the "Edit Plant" form by default.
• Probably, the "Configure Form" menu gets some options to let you switch edit forms and edit the task using a different form. This would let you edit all the fields of a "Plant" if you need to, and make Simple/Advanced flows generally more reasonable.

The major question here is whether we're just storing which form you used, or storing an actual formal subtype.

This is probably the most critical issue to resolve.

Weakness: No Formal Subtypes

Tasks currently have no formal subtype: there's no such thing as a "plant task" vs an "animal task".

You can informally subtype tasks by adding project tags, as we do on this install: feature requests and bug reports get default-tagged with Feature Request and Bug Report. This works pretty well in this use case -- and we would probably want to do this anyway, even with formal subtyping, because it's useful to be able to list and search all bug reports or feature requests and we use their workboards occasionally.

However, this isn't as powerful as formal subtyping would be. It can also create states -- like a task tagged with both projects -- that don't necessarily make sense if we're going to treat subtypes as a more first-class idea.

(As an aside, I don't immediately see any reason that we couldn't support multiple subtypes on a single task. However, I think this is probably confusing nonsense and not a good idea.)

I am leaning toward formally defining subtypes, and having forms optionally imply a subtype. I think the biggest drawback to this approach is that we have to introduce another new first-class idea into the application, but I think this is how users are most likely to think about subtypes (rather than some sort of path-dependence on which create form was used) and it gives us more obvious answers to some other questions and more flexibility around how forms and subtypes interact.

Weakness: Templating
Related Tasks: T10719

When you use a task as a template with "Create Subtask" or ?template=X, a static set of fields is copied from the template (Custom Fields can be configured as copyable). This set of fields is normally fairly reasonable, but not always what users want.

There's a lot of discussion in T10719 and no clear pathway forward. This may eventually interact with subtyping, but subtyping may also give us some tools to attack it (copyability per-subtype?).

This is not important to resolve. The current behavior is good enough in most cases, and not unreasonably onerous to correct in others.

Weakness: Copy / Create Another

Long ago, we had a "Create Another Similar Task" option after creating a task, and a "Create a Copy of This Task" option. Of these operations, only "Create Subtask" survived.

It's not clear that removing these was a mistake and we haven't seen any requests to restore them, yet, that I can recall. However, I've seen a couple of related requests in downstreams, and these options are perhaps worth thinking about in the context of these other changes.

This is not important to resolve. We have seen little demand to restore these options.

Weakness: Changing Subtypes

If we introduce subtypes (whether formal or just "sticky forms") we likely need some way to allow you to swap a task between subtypes.

This is presumably uncommon, and we can probably bury it in the "Configure Form" menu.

Some open questions:

• If "Animal" has some required fields, and you change a "Plant" into an "Animal", how do we ensure the fields are populated?
• If you change a "Plant" into an "Animal", what happens to the values in "Plant"-specific fields?
• If you change a "Plant" into an "Animal" and then back into a "Plant", did a bunch of data get destroyed?

A somewhat-related operation is merging tasks. Can you merge a "Plant" into an "Animal"? Which fields get copied/updated?

This is not important to resolve. We probably don't even need to make subtypes mutable initially, since you can always just copy the fields by hand. I expect users will make mistakes with this frequently enough to motivate providing this capability eventually, but it's also not terribly critical to get it exactly right in all cases since it's already an "oops, let's clean up a mess" workflow.

Weakness: Communicating Subtypes
Related Tasks: T4863

If we introduce subtypes, we need to show them to users somehow. This isn't too tricky but overlaps T4863 on workboards.

Weakness: Nuance Overlap
Related Tasks: T8783

Nuance is our planned "helpdesk" tool for processing higher-volume queues of human intelligence tasks (like responding to support email). At least some use cases for task subtyping today may be a much better fit for Nuance once it is built. Nuance is on the relatively short-term roadmap and if we went all-out on subtyping now, we might look back in 6-9 months and regret some of the decisions (for example, see ways we could have simplified Maniphest/subtypes by pushing more use cases into Nuance instead).

I think there are a large number of legitimate use cases for subtyping in Maniphest and that the feature would still be worthwhile even if we had a fully-realized Nuance implementation today. However, I want to be cautious about overcommitting development effort to making subtyping handle a wide variety of different use cases until Nuance is more clearly defined.

Weakness: Manual Test Case Overlap
Related Tasks: T7190, T9652

This tool doesn't have a name yet and these issues are only very tangentially related, but some use cases which could potentially be accomplished through subtyping are likely better fits for the "manual checklists" tool we may eventually build.

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.

This isn't a real concern, but if other applications could benefit from these infrastructure changes that would motivate them more strongly.

So here's a tentative plan for subtyping:

• We allow you to formally define subtypes in some kind of new configuration option like maniphest.subtypes. For example, you might define "plant" and "animal" subtypes. Subtypes would have some things like a name, a unique key, an icon, and maybe some other options. There is always a "default" subtype which you can customize but can not remove.
• Task forms get a "subtype" option, which allows you to define that a particular form creates or edits "plant" tasks or "animal" tasks.
• When we build the "Create" menu, we show you all create forms for all subtypes that you have access to.
• When you create a task, we save the subtype on the task formally. You can search for tasks with particular subtypes, and the task detail page shows the task subtype. The workboard card probably also shows the subtype if we can fit it on there.
• When you "Edit" a task, we choose the default edit form for that task's subtype.
• The "Configure Form" menu gets some new options to let you edit the task using a different edit form. This is primarily a "clean up messes" workflow and doesn't necessarily follow all the rules perfectly for now.

Then carve this out as future work:

• For now, there's no support for changing task subtypes, although we'll expect to build this eventually. You can always copy/paste the field values.
• For now, we either don't change workboards or just put all the global options into the menu, probably?
• For now, "Create Subtask" picks the first edit form of the parent's subtype (so if you "Create Subtask" from an "Animal" task you get another "Animal").

I want to think about this for at least a day or two before moving forward with it (and maybe @chad or others have some thoughts?) but I think this is a fairly reasonable extension of the current Custom Forms that would provide meaningful subtyping while retaining the existing flexibility.

The workflow you describe would then look something like this:

• You would define two new task subtypes ("Security", "Risk") and rename the default type to "Feature".
• You would create three Custom Forms: "New Security Task", "New Risk Task", "New Feature Task".
  • On each form, you'd hide all the custom fields which are not relevant to that task type and make any other changes you want (defaults, instructions, reordering fields).
  • You would specify that the "New Security Task" form creates tasks with the "security" subtype, and likewise for the other two forms.
  • You would configure all three forms as create and edit forms.
• Then, Maniphest would give you options in the "Create Task" dropdown: "New Security Task", "New Risk Task", "New Feature Task".
• Selecting those options would take you to a form with appropriate fields (and, optionally, instructions and defaults).
• Submitting those forms would create tasks with formal subtypes.
• Selecting "Edit Task" on the tasks you created would edit using the appropriate form for the task's subtype.

Additionally, you could do these things:

• Provide multiple workflows to create any of these task types (for example: basic vs advanced).
• Customize create vs edit workflows (for example: simplified layout and instructions when creating, with a more streamlined form with more options when editing).
• Control access to different workflows (for example: give new users a simplified "Security" workflow, and experienced users a more advanced one).

I think the major downside is that this is a bit more complicated to set up than a more limited system, but it's much more flexible and fits cleanly into the existing infrastructure and capabilities provided by Custom Forms, and compliments them rather than conflicting with them.

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

Not sure what this means. I presume if it's a plant task, clicking the edit icon on the task while on a workboard still opens the plant edit form. Though maybe you mean something else? New tasks created on a workboard?

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

We could make it do this instead (for example, on this install):

New Task
New Bug Report

New Feature Request

Batch Edit Tasks...
Hide Column

That's pretty easy and doesn't feel excessively heavy to me, but moves us away from one-click-create (T6064) which I think you'd wanted to restore eventually.

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.

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

"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. "

Consistency in the UI for creating tasks, whether at the top-level or for sub-tasks seems worthwhile just to avoid confusing users.

"Weakness: Tasks Don't Remember Which Form They Were Created With" - I agree that this is the most critical issue to resolve, but it's absence doesn't stop us from making progress.

We don't need to be able to change subtypes for our use case.

All in all your tentative plan looks good to me and would fit our use case well!

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.

thanks, sounds great!

One other related requirement that I forgot to mention is the ability to lock a task at some point from further changes - should I file a separate feature request for that? Thanks,

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

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.

Overall, the major behavioral change here is that when users click "Edit Task", the form they end up on can now depend on the form that was used to create the task.

For this example, I'm going to walk through defining a new "Plant" subtype and a new "Animal" subtype. These probably aren't useful to solve real problems, they just make the examples more clear. Before getting started, I've added some custom fields locally: one called "Animal Type" (which I only want to appear on "Animal" tasks) and one called "Plant Habitat" (which I only want to appear on "Plant" tasks):

We've introduced a new maniphest.subtypes option in Config, where you can configure subtypes. Start here by defining the subtypes you want to use. In this example, I'm leaving the default subtype as "Task" and defining two new subtypes:

On its own, this won't do anything. Without additional changes, all tasks will still be created with the "default" subtype, and use normal create/edit rules for selecting forms. The next step to make subtypes actually work is to configure some forms for them.

In Maniphest → Create Task → Configure Form → View Form Configurations, I've created two new forms to supplement the builtin form. These forms will be used to create and edit plants an animals:

On each form's configuration page, I made these changes:

• I've marked them as "Create" and "Edit" forms.
• I've used the new action, Change Form Subtype, to select the correct subtype.
• I've hidden fields which are not relevant for that subtype, and made other appropriate adjustments (field order, defaults, etc).

Here's a screenshot of setting the subtype on the "New Plant" form:

You can preview what these forms look like with Use Form. Here's what the "New Animal" form looks like after my changes (for this example, I hid most of the fields, and put "Animal Type" near the top):

With everything configured, Phabricator now has several new behaviors. First, the "Create Task" dropdown in Maniphest allows you to choose which type of task to create:

Workboard columns now offer the same choice:

When you create a task with a particular form, like the "New Plant" form...

...clicking "Edit Task" will now use forms with the same subtype (in this example, there's only one, so you get the same form):

This also applies if you edit the task from a workboard or from the task list, using the "" action links.

A new "Subtypes" constraint on the search form appears if you define at least two subtypes (that is, the "default" type plus one new subtype). This lets you search for tasks with a particular subtype:

In Conduit, maniphest.search returns a new "subtype" field and maniphest.edit accepts a new "subtype" transaction.

These new features should compliment and support the existing Custom Forms features documented in User Guide: Customizing Forms, so everything that document discusses should work here (for example, you can limit which users are allowed to create "Plant" tasks, or provide different simple and advanced forms for interacting with "Animal" tasks).

Feedback / Future Work

• This is brand new and might be buggy, let us know if you run into issues.
• There's no UI hint about which subtype a task has.
  • Workaround: you can look in the subtype column in the phabricator_maniphest.maniphest_task database table if you're trying to debug something.
  • Workaround: the Conduit maniphest.search method returns subtype information.
  • D17451 has some rough approaches, but we aren't yet sure how we want to show this in the UI or if it's even necessary: the subtype of a task might always be fairly self-evident from context.
  • If it feels like this information is missing in practice, feedback about the issues or confusion that you're seeing users run into would help us move forward here.
• There's no way to change a task's subtype after it is created, and no UI link to edit it using a form of a different subtype.
  • Workaround: you can apply a subtype transaction via maniphest.edit.
  • Workaround: you can manually access /maniphest/task/edit/<task-id>/form/<form-id>/ to edit a task with a different form.
  • Workaround: you can create a new task and copy/paste information.
  • It's unclear if this is important, or what the best way to approach it is. If you run into issues with this, feedback about the problems you're hitting and the circumstances in which you want to change a task's subtype would be helpful in choosing a solution.
• Some custom field interactions may still be a little rough or labor-intensive.
  • There's no way to prevent "Label" custom fields from appearing on all task subtypes. Not sure if this is important in practice; subtyping might solve the same problems in a cleaner way. There might be some similar cases with other field types.
  • If you add new custom fields, you may need to go manually hide them on existing forms. This is probably fine if you have 3-5 forms. If you end up with 30, it might become a laborious chore.
  • If you run into issues here, let us know.
• No documentation yet. This comment is the documentation for now, since this feature might evolve a bit still and I don't want to write up some documentation and then have to rewrite the whole thing.
• The edge case stuff, like merging an "Animal" into a "Plant", doesn't try to do anything special. Most of these behaviors should generally be fine as-is, but let us know if anything feels like it doesn't make sense.

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.

Funnily enough, I've always thought that calendar events should be a subtype of maniphest tasks. Or even better, it would be really awesome if event and task were just traits of a phobject with associated data/behavior like start time for events and resolvable for tasks. In a perfect world, each trait could be cleanly combined create various custom object types.

Another sort of related thought: project types comes to mind as another place where sub-typing would be useful. I can imagine having some custom behaviors and form fields associated with the various project type icons. But I don't know how useful that would be in practice.

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.

The proposed solution that immediately pops into my head would be to allow the "create new" menu to vary. Either it would show the subtypes related to the project(s) you are currently viewing, or related to the project(s) you are a member of. Then there would be some kind of "more" or "other" option that would allow you to create a new task outside your current/normal project(s).

I don't know if that would actually work or otherwise be practical, but I wanted to share my concern, and one possible solution. If every "create new" menu in the entire phab instance has to be the same for all users at all times, I'm not sure we'll end up adding any subtypes, because it seems like it will be really hard to gain anything close to consensus for even one.

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

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

We should probably add this new favorites feature to our internal phab documentation. I don't see it there yet, and it's a feature I was not aware of. I'll follow up with you in a different channel for that.

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?

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?

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?

It still needs to be added. I'm not sure if a { "required-for-subtypes": [ "vegetable", "mineral" ] } to replace required in custom fields is best, or perhaps just subtypes, which a) doesn't present the field in any forms not for that subtype (resolving @epriestley's concern above), and b) doesn't do required validation for that field if the task is not of that subtype (resolving your concern). Probably the latter.

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

For most fields (e.g., text or description fields) my expectation is that the fields don't render if they don't have a value, and "Animal" tasks normally won't have values for any "Plant" fields.

For some fields (e.g., header fields), my thinking was that this feature might mostly make them unnecessary.

But I'm not sure if all fields fall into one of those categories. Maybe you're seeing issues with other field types -- just guessing, maybe select/dropdown fields?

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: probably should not have a default value.

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

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

I think the answer is no, you have to hide them manually but if that is the case, is there any plan to make them hide automatically? Perhaps along the lines of:

1. Default task has all field definitions for all subtypes
2. If a field has a key for a subtype, only show the specified subtype
3. If a field is a "default" key, show on all and require manual hiding

This might result in field duplication but might make for a cleaner interface when creating a form and make the required interaction simpler as mentioned above.

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

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.

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.

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

This is a problem that epriestley already called out in a previous comment but I want to add my strong support for some solution to this scalability issue.