Configure project-level issue custom field with enumerated (dropdown) field type
Description
- Configure custom fields at the project level.
- The field is an enumerated field type.
- There is a limit on the number of number enumerated options. Each option itself is a text entry. So for example, you can define a custom field called:
Operating system
, and the enumerated options could be calledAndroid
,iOS
,Linux
. - There is a limit on number of enumerated options.
- The options are an ordered list. So there is a defined first option.
- Each custom field must have at least two options.
- Each custom field is manadatory. I.e. an issue with the custom field must take on at least one of the values. It cannot be null.
- A custom field value can only be changed by a reporter or higher role.
- When you create an issue, guest roles cannot set the custom field value. Instead it takes on the default value. If you are a higher role, you can change the value during issue creation. Issue creation in the API or via the plus button in a board would result in creating an issue with default values for the custom fields.
- There is a limit on the number of enumerated fields per project.
- We have to handle what happens when you delete one of the field's options. See technical performance considerations below.
Consistency design details
We should do whatever is simplest to create and maintain from an 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 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.
Technical performance considerations
We want to avoid processing large amounts of data whenever changes are introduced. For example, if a new custom field is added, or a given option for a given existing custom field is removed, it probably doesn't make sense to iterate over all issues and adjust their values.
I (Victor) suggest using a lazy-loading technical approach. Anytime you need to access an issue's custom fields, that's when you evaluate its values. For example, if you have added a new custom field in the settings, you don't need to immediately add that to all issues. Instead, whenever you access a given issue, check if the custom field in question is populated. If not, then simply populate it with the current default value of the custom field. Similarly, an admin has deleted one of the options of a custom field. And now you are accessing an issue with that custom field with that deleted option. At that time, GitLab will recognize that that option is no longer applicable, and replace it with the default option.
New custom field
- There are 123 issues in the project.
- An admin creates a new custom field
operating-system
with three options, in this order:Android
(default option),Cupcake
,Eclair
,Froyo
. - All 123 issues at least semantically get
Android
as the value ofoperating-system
. (Whether we actually add values in the database to make those 123 associations at this point in time, is the topic of this discussion.) - A regular user goes to the issue list (Web UI or API) and filters on
operating-system: Android
. GitLab should return all 123 values. I think this makes sense because a use case here would be the admin going through all 123 issues and assigning Android versions one by one on each issue. And the admin wants to keep track of which issues haven't been reviewed and assigned yet. So they have a browser tab open with the filteroperating-system: Android
and keep refreshing it to keep track.
An option is deleted
- Suppose 35 of the issues have
Eclair
assigned tooperating-system
. - The admin goes into the settings and deletes
Eclair
as an option. - Those 35 issues should now at least
semantically
haveAndroid
be theoperating-system
value. - When a regular user goes to the issue list (Web UI or API) and filters on
operating-system: Android
, GitLab should include those 35 issues in the result set.
Tier
See &235
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.