Configure group-level issue custom field
Description
- 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
None
and<some text>
. - 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.
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.