Page MenuHomePhabricator

Custom project fields do not appear in the Create New Project
Closed, ResolvedPublic


Custom fields defined for projects which have the "required" bool set to true display fine on the edit project window, however custom fields do not appear at all on the "Create New Project" window.

If a custom field is set to be required, it will not be displayed on the "Create New Project" screen, however the screen will also not allow the user to progress with project creation until these (missing) fields are completed.

i.e. error:

FieldName is required.

Event Timeline

r0bbie created this task.Sep 19 2014, 10:59 AM
r0bbie raised the priority of this task from to Needs Triage.
r0bbie updated the task description. (Show Details)
r0bbie added a project: Projects.
r0bbie updated the task description. (Show Details)
r0bbie added a subscriber: r0bbie.
chad renamed this task from Custom project fields do not appear in the "Create New Project" window but can also be set to be "required" on that screen, blocking project creation. to Custom project fields do not appear in the Create New Project.Sep 25 2014, 10:13 PM
epriestley added a subscriber: epriestley.

Support Impact This completely breaks the interface.

chad triaged this task as Normal priority.Oct 3 2014, 11:22 PM
chad added subscribers: btrahan, chad.
btrahan claimed this task.Oct 10 2014, 6:15 PM

See also T4016.

A possible approach might be to add a key like quick => true to add custom fields to the quick create interface.

We could also remove this interface completely, or replace it with the full-power interface and remove the "quick" flavor.

chad added a comment.Oct 10 2014, 6:23 PM

Yeah, just make it a full dialog / workflow. No need for two different forms.

Oh, I'm actually misunderstanding this a little bit.

There are two ways to get to project creation:

  • In Maniphest, click Edit Task > Projects > Create New Project. I think this action appears on some other (but not all) "Project" fields.
  • In Projects, click "Create New Project".

T4016 discusses the former interaction. Both of them might actually go down the same code pathway.

The second interface, at least, should probably be a normal full-sized edit screen.

The first interface should either also be that (and the interfaces should be unified if they aren't already unified) or some "quick" flavor, maybe with a quick specifier.