Configure group-level issue custom field
- Configure custom fields at the group level.
- The field type is just a free-form GFM text field with no validations. So the allowable values are
- By default, the number of custom fields is zero, so that people who don't want to use the feature, won't see it in there daily usage. It won't be in the regular issue UI. But for people who are interested in custom fields, they will be able to seek it out. So it is okay that this feature has a bit of friction in terms of discovery.
- In the group-level configuration, admins can create any number of custom fields.
- You can edit the custom field name.
Consistency design details
We should do whatever is simplest to create and maintain from a engineering perspective. Custom fields are already a very complicated and powerful feature. Especially in the first iteration, we should trust the user to make good decisions and keep the implementation very simple. My proposal for keeping it simple:
- You can create any number of custom fields (at the group level), which issues will use.
- You can delete custom fields. If you choose to delete, there is a big warning flow telling you that all the associated data would be deleted, which is what would happen.
- When you create a new custom field, there is no validation on field name uniqueness. So you can have two fields with the same name.