I'm going to close this; there are two possible followups -- each of which is better focused on a more specific set of problems -- but I'm not merging it into either one since I think there's a lot of general ambiguity about problems and use cases here. If you're interested in this, feel free to follow either or both.

Just merging this over to Facts, I don't anticipate allocating any resources to Maniphest reports before Facts ships.

Specifically, you will be able to get this information from Facts.

It's correct, we will not be allocating resources to fix this before shipping Facts.

@chad: Errrm, I assume that translates to "wontfix"? Because I don't see how a specific well-defined issue in an existing part of Phabricator is a duplicate of "Build some new tool".

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

For those looking for how to associate tasks to columns - reference the following from T12074:

Then please fork Phabricator to provide this option on your local install. One interested party every few years isn't enough interest for us to add an option, and it's probably 1-2 lines of code for you to provide it for yourself.

I disagree. This option is a lot like email notification options which are already present in Phabricator. It expresses very personal preferences of how user prefers to read the same content. And for me it is more important than ability to set board backgrounds.

See T8227: Why not just add an option/setting/preference?

Hello, here is my use case.

T12335#214054 discusses some future/followup work, but that can be filed separately as it becomes relevant.

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:

Why the export does not contains the task author?

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

Yep, thanks!

It's possible T10872 is also related/is a duplicate.

With subprojects, #project changed to mean "that project, and all its descendant projects", but any(...) and not(...) still mean "just the parameter, exactly". I think viewerprojects() and projects(user) are also "just the parameter".

I can confirm that In Any: does not seem to include subprojects. I tried to make some sense of the way the project search functions work but it's pretty complicated.

@beber, please file a new task with reproduction instructions that work on a clean install if you believe you've found a bug.

Tezt comment

Any resolution/guide how to avoid that obstacle ?

Thanks for catching this, and for the clear reproduction steps.

I think the way the view gets built is a little odd and I didn't get the logic quite right. Definitely a bug, thanks.

I have to report a possible bug as asked in Q584.
Message for editing locked task when create new non-existing task:

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

One use case for "locking" a task could be:

1. For a release of the software product all tasks which represent the software changes on the version being released require review
2. Reviewer looks over task form fields and if everything looks good, "signs" (locks) the task in a "reviewed" state
3. Tasks can be unsigned prior to release of the version, allowing updates to tasks as necessary but also requiring another review
4. Upon release of the version, tasks can no longer be unsigned

We've implemented a basic version of this, roughly along the lines of the recommendation above. Here's how it works:

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.

I can confirm that advisory locking is acceptable. Locking the whole task is preferable, but we can live with comments not being locked. Thanks!

Q. Common or rare?
A. Common - we'd lock all tasks before a release.
Q. Lock comments? Do you need to lock comments too, or just other types of edits (like status, priority, title, description, etc)?
A. I'm ambivalent about this, if the lock is mandatory then being able to add comments seems reasonable since someone can point out that the task needs to be unlocked for some reason or other.
Q. In particular, could a solution where anyone could unlock the task be acceptable, as long as they had to explicitly unlock it? Or is it a hard regulatory requirement that unlocking requires some sort of administrator/oversight step?
A. Unclear, I'll ask, but it's probably fine since there's also a 'process' that states how people use the system. (And you'd be surprised how much drama there is inside private companies:-) That is, our conventions are formally documented and people expected (and expect) to follow them.
Q. Lock other objects?
A. Possibly, but I've been pushing back on it for things like code reviews by arguing that 'everything is logged and there's an audit trail' so what does a lock by us? Obviously locking git doesn't really make sense and new comments can't hide old ones so I don't see what the problem is. For tasks, I don't feel I can make that argument since people will naturally just look at the current state of the task unlike code reviews where the history is 'in your face' as it were.

I have a few questions about this, and some ideas for how we could solve it:

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

thanks, sounds great!