Change Details

See PHI1393. If you specify that a custom field is both "required" and "disabled", the "required" attribute is currently stronger. This is less useful than making "disabled" stronger. Until fields conditioned on subtype came around this configuration was somewhat nonsensical. You could maybe use it to temporarily hide a field, but it didn't really make a ton of sense. However, it's meaningful and useful now that you can have different fields on "Bug" and "Fish" task subtypes, and requiring a "Swimminess" value on Fish but not on Bugs is perfectly sensible. To reproduce simply: - Define a custom field in `maniphest.custom-field-definitions` that is both "disabled" and "required". - Create a task. Desired behavior: - Field does not appear, no errors, creating a task works fine. Actual behavior today: - Form submission fails with an error that the field is required (even though the field is not visible on the form and can not be filled out).

See PHI1393. If you specify that a custom field is both "required" and "disabled" (via subtypes), the "required" attribute is currently stronger. This is less useful than making "disabled" stronger. This configuration is meaningful and useful now that you can have different fields on "Bug" and "Fish" task subtypes, and requiring a "Swimminess" value on Fish but not on Bugs is perfectly sensible. To reproduce simply: - Define a custom field in `maniphest.custom-field-definitions` that is and "required", then make it "disabled" on some subtype (say, subtype X) with subtype config. - Create a task of subtype X. Desired behavior: - Field does not appear, no errors, creating a task works fine. Actual behavior today: - Form submission fails with an error that the field is required (even though the field is not visible on the form and can not be filled out).

See PHI1393. If you specify that a custom field is both "required" and "disabled" (via subtypes), the "required" attribute is currently stronger. This is less useful than making "disabled" stronger. Until fields conditioned on subtype came around this configuration was somewhat nonsensical. You could maybe use it to temporarily hide a field, but it didn't really make a ton of sense. However, it'This configuration is meaningful and useful now that you can have different fields on "Bug" and "Fish" task subtypes, and requiring a "Swimminess" value on Fish but not on Bugs is perfectly sensible. To reproduce simply: - Define a custom field in `maniphest.custom-field-definitions` that is bothand "required", then make it "disabled" and "required"on some subtype (say, subtype X) with subtype config. - Create a task of subtype X. Desired behavior: - Field does not appear, no errors, creating a task works fine. Actual behavior today: - Form submission fails with an error that the field is required (even though the field is not visible on the form and can not be filled out).