Custom fields in issues
- #1906 Custom fields in issues
- #2493 Custom fields with required validation
- #2503 Custom fields in groups
- #2504 Custom fields with enumerated field type
- Configure custom fields for issues at the project level.
- You can add any number of fields in the project settings.
- You can remove fields in the project settings.
- When adding a field in the project settings UI, you can specify a field name. The field name can be changed.
- There are no validations on the field names or field values. So for example, two field names could be the same.
- There should be the standard security protections in place. So you cannot do SQL injection, for example.
- You can change the field names in the configuration.
- Only users who have access to the project settings can make these configurations.
- Any user who can edit the description in an issue can update the field value in the issue itself.
- There is no validation or constraints not the fields. You can leave it blank if you want, and you can enter any length.
- The field type for this first iteration is a plain text field.
- No other field types are available.
- The API should be updated so that when users query on an issue, they get all the field names and field values returned.
When the feature is released, existing legacy issues will also get the fields. They will be blank. But you can go back to those issues and enter values into them.
Edge case that needs further engineering feasibility discussion: What happens when you delete a field in the configuration? Does it remove all values from all issues that already have data? Do those values stay associated with those issues forever?
In the example design mockup below, there are over two fields here. You click
View allto pop up a modal to view all fields. You can also click
Editto get to the modal and enter edit mode, where you can make updates to the fields.