Hello;
I write this because i could not find a nice solution to the problem described below. If this can be solved without modification of Phorge, i am happy to learn how it is done.

Assume you define a custom field and a few task subtypes.
Assume further some subtypes need this field to be mandatory, other subtypes need it to be optional and some subtypes do not need this field at all.

The issue:

To make a field required, i must define this in the field definition but this is static, so the field is now always required. This works for subtypes which need the field to be required.

For subtypes which need the field to be optional i can in principle add default values. This works reasonably well for text fields where i could add a place holder text and for option fields i could add a "not applicable" entry, which works but is a bit odd since the user always can remove a field entry and then get faced with a "this field is required" warning.

for subtypes which do not need the field at all i still could put default values into the fields and then make them invisible.
This works also, but at the end i see all the default entries for the invisible required fields in the Task overview page.

There is an option to disable fields for some subtypes. However that only works for optional fields. When i disable a required field, then i can not even create a task because a disabled field can not be filled with values, Phorge always reacts with "required field not set" in this case.

Some ideas for solving:

Unless i am unaware of an existing solution to this issue i propose to improve the subtype support as follows:

• Add a 'default' attribute for custom fields which would allow to preset field values regardless whether they are enabled or disabled in a subtype.
• Add a 'default' attribute into the subtype fields definition (regardless whether the field is enabled or disabled)
• Automatically Set the field value of hidden required fields to their default value
• Prevent the display of required hidden fields if they have been preset with their default value.
• Add a 'required' attribute into the subtype fields definition.

Note that it is not necessary to implement all of the above proposed measures since most problems can be solved with intelligent (albeit a bit odd) setup of the configuration. However IMHO at least disabled required fields should be treated as if they where not at all defined to handle required/optional/hidden fields per subtype.