Change Details

See also PHI1051. Previously, see D17593, and some discussion in T12314. Various reasonable use cases exist for having some fields present only on objects of certain subtypes. For example, a "Carapace Color" field might only be relevant on "Bug" subtasks, not "Fish" subtasks. I want to implement this as `"fields": { ... }` override on the subtype (as suggested in D17593), not a `"subtypes": [ ... ]` configuration on the field (as originally proposed in D17593), because I think this gives us greater flexibility to customize more behavior based on the subtype (for example, to change the label, caption, etc). At least until bigger problems arise, I think we can cheat our way through this in `getCustomFieldSpecificationForRole()`. This doesn't feel //great//, but is a relatively small patch, and more-or-less the right place to put things to pursue the broader goals of letting subtypes override a significant amount of field behavior. The only immediately obvious challenge is that some roles are generic and evaluated against a default object. In these cases, any overrides on the default subtype should //not// be used. For example, if you view `/maniphest/` and get the task search view, you should be able to use all available fields to search -- not just the fields present on the default subtype. In `getCustomFieldSpecificationForRole()`, we can't examine the object itself (`$this`) to make a determination about whether the subtype matters or not, but should be able to examine the `$role`. --- Future work: - When you search for objects with value "X" in custom field "Y", we'll naively return objects of subtypes which hide the Y field. They may have a value in Y if they were previously an object of a different subtype and changed subtypes. We could fix this by testing each subtype for presence of each custom field constraint, and including an `AND subtype NOT IN (...)` clause in the final query.

See also PHI1051. Previously, see D17593, and some discussion in T12314. Various reasonable use cases exist for having some fields present only on objects of certain subtypes. For example, a "Carapace Color" field might only be relevant on "Bug" subtasks, not "Fish" subtasks. I want to implement this as `"fields": { ... }` override on the subtype (as suggested in D17593), not a `"subtypes": [ ... ]` configuration on the field (as originally proposed in D17593), because I think this gives us greater flexibility to customize more behavior based on the subtype (for example, to change the label, caption, etc). At least until bigger problems arise, I think we can cheat our way through this in `getCustomFieldSpecificationForRole()`. This doesn't feel //great//, but is a relatively small patch, and more-or-less the right place to put things to pursue the broader goals of letting subtypes override a significant amount of field behavior. The only immediately obvious challenge is that some roles are generic and evaluated against a default object. In these cases, any overrides on the default subtype should //not// be used. For example, if you view `/maniphest/` and get the task search view, you should be able to use all available fields to search -- not just the fields present on the default subtype. In `getCustomFieldSpecificationForRole()`, we can't examine the object itself (`$this`) to make a determination about whether the subtype matters or not, but should be able to examine the `$role`. --- Future work: - When you search for objects with value "X" in custom field "Y", we'll naively return objects of subtypes which hide the Y field. They may have a value in Y if they were previously an object of a different subtype and changed subtypes, or possibly because of default field value behavior. We could fix this by testing each subtype for presence of each custom field constraint, and including an `AND subtype NOT IN (...)` clause in the final query. - There's currently no way to disable a field by default. It would probably be useful to let a field specify that is is disabled by default, then enable it only on specific subtypes. Currently, you would need to disable it on all subtypes where you don't want it. - When you export tasks (e.g., to a spreadsheet), the subtype filtering currently does not apply. It probably can and should: we'll still export the column named "Carapace Color", but leave it empty for tasks of a subtype which does not use the field.

See also PHI1051. Previously, see D17593, and some discussion in T12314. Various reasonable use cases exist for having some fields present only on objects of certain subtypes. For example, a "Carapace Color" field might only be relevant on "Bug" subtasks, not "Fish" subtasks. I want to implement this as `"fields": { ... }` override on the subtype (as suggested in D17593), not a `"subtypes": [ ... ]` configuration on the field (as originally proposed in D17593), because I think this gives us greater flexibility to customize more behavior based on the subtype (for example, to change the label, caption, etc). At least until bigger problems arise, I think we can cheat our way through this in `getCustomFieldSpecificationForRole()`. This doesn't feel //great//, but is a relatively small patch, and more-or-less the right place to put things to pursue the broader goals of letting subtypes override a significant amount of field behavior. The only immediately obvious challenge is that some roles are generic and evaluated against a default object. In these cases, any overrides on the default subtype should //not// be used. For example, if you view `/maniphest/` and get the task search view, you should be able to use all available fields to search -- not just the fields present on the default subtype. In `getCustomFieldSpecificationForRole()`, we can't examine the object itself (`$this`) to make a determination about whether the subtype matters or not, but should be able to examine the `$role`. --- Future work: - When you search for objects with value "X" in custom field "Y", we'll naively return objects of subtypes which hide the Y field. They may have a value in Y if they were previously an object of a different subtype and changed subtypes, or possibly because of default field value behavior. We could fix this by testing each subtype for presence of each custom field constraint, and including an `AND subtype NOT IN (...)` clause in the final query. - There's currently no way to disable a field by default. It would probably be useful to let a field specify that is is disabled by default, then enable it only on specific subtypes. Currently, you would need to disable it on all subtypes where you don't want it. - When you export tasks (e.g., to a spreadsheet), the subtype filtering currently does not apply. It probably can and should: we'll still export the column named "Carapace Color", but leave it empty for tasks of a subtype which does not use the field.