Page MenuHomePhabricator

Make custom field visibilty dependent on custom task type field
Closed, WontfixPublic

Description

Is it possible to only show custom field in task properties, depending on another option property?
The goal woud be to have certain task types, e.g. "bug", "feature", "discussion", "milestone", etc., and only show custom defined "deadline", "estimated work", or "actual work" fields for tasks with types where these fields are actually relevant.

Event Timeline

timor raised the priority of this task from to Needs Triage.
timor updated the task description. (Show Details)
timor added a project: Maniphest.
timor added a subscriber: timor.

I am interest in the same solution...

You can (sort of) do this today by writing event listeners

https://secure.phabricator.com/book/phabricator/article/events/

...the "sort of" bit is that complicated, client-side interactions wont work; like if you wanted to add a custom field type for "task type" and then have different fields show / not show as the user updated the task type, that wouldn't work.

What is very possible though is say on the initial load, if the type was 'bug' you could have the 'bug' fields show up. This is actually most of the cases except for edits that change from type a to type b and want to fill out new information for type b all in one go.

I'll have to defer to @epriestley and @chad if they think adding support for this at a lower level is a good product decision. It strikes me as a rather complicated feature but hidden enough such that it won't burden non-users of the feature. Technically speaking, I think for the client-side complicated interactions to work the HTML would have to be the superset of every possible field, with some new javascript smartly hiding / showing what is and is not there.

I think we might get here eventually but it involves a bunch of messy JS or a two-phase create screen, and then things get extra messy if the type is mutable. The search interface also always has to show all the fields.

In the cases of "discussion" and "milestone", I'd expect them to eventually move elsewhere (Conpherence / Projects) and/or for it to not be a big deal to have the extra fields. For example, we have some discussion/guide type tasks and not all the fields (assigned to, priority) are really relevant, but we just ignore them, and that's probably less effort on the balance than having to choose between "task" and "off-label task-like thing" when creating a task.

We implemented something like this for our install using custom fields that only show if a task has a certain project attached to it.

You can see an example here: https://github.com/bluehawk/phabricator-sprint/blob/master/src/SprintTaskStoryPointsField.php

Now if you go to a Sprint project, and clink on "New Task" it creates a new task, and since the project is already filled in, the Story Point field shows up.

epriestley triaged this task as Wishlist priority.Sep 18 2014, 12:35 AM

See also T6114, which is similar. We may eventually pursue this, but do not have an plans to move forward with it at this time.

epriestley claimed this task.

I don't currently plan to pursue this, as I think form customization fixes about 80% of this problem by letting you create multiple different create forms (as on this install), and will likely get to 85% or 90% with further refinement.

If we do move forward here, it would be in terms of form customization (e.g., have edit forms be "sticky" on tasks, so you edit them with the same form you created them with, by default, or similar) but I'd like to see renewed interest in the context of the modern form toolset before pursuing that.