Work Item Custom Fields (#235) · Epics · Epics · GitLab.org

Work Item Custom Fields

_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._  > [!note] Current status > MVC1 was delivered with the 17.11 release (https://gitlab.com/groups/gitlab-org/-/epics/235#mvc1-basic-fields). MVC2 and MVC3 are pending prioritization. ## Problem The only way to currently map organization-specific data to work items in a structured way is via labels. Labels are not flexible enough to efficiently or accurately represent all the different data types that organizations need to track within GitLab. ## UX Research - https://gitlab.com/gitlab-org/ux-research/-/issues/2771+ - https://gitlab.com/gitlab-org/ux-research/-/issues/3256+ (`@gweaver` is currently anti-enforcement. Leave a comment on the research issue if you feel strongly that GitLab should support mandatory fields, including custom fields, and include your use case) ## Custom Fields UX/UI https://gitlab.com/gitlab-org/gitlab/-/issues/461471+ ## Tier Tentatively, simple custom fields will be in ~"GitLab Premium" and more complex custom fields with advanced configuration controls will be in ~"GitLab Ultimate". ## Implementation Spike https://gitlab.com/gitlab-org/gitlab/-/issues/472640+ ## Work item type scopes - :white_check_mark: Epics - :white_check_mark: Issues - :white_check_mark: Tasks - :white_check_mark: Objectives - :white_check_mark: Key Results - :white_check_mark: Incidents - :white_check_mark: Tickets (if this exists as a work item type today) - :white_check_mark: Requirements - :white_check_mark: Test Cases ## Iteration plan ### :white_check_mark: MVC1: Basic fields https://gitlab.com/groups/gitlab-org/-/epics/14904+ To track the progress of individual vertical feature slices, expand this subepic from the child items widget below. <details> <summary>View old breakdown</summary> Scenarios to support: - _As a `Maintainer+`, I can create a custom field in a root namespace._ - _As a `Guest+`, I can enter values for custom fields when creating a work item._ - _As a `Reporter+`, I can update the the values for custom fields on work items._ Tasks: - Navigate to `Settings > Work Items > Custom Fields` - Base tables for EAV schema ~backend - Application limit for max custom fields in a namespace: `30` {+ proposed, need to validate +} ~backend - Document limit in https://docs.gitlab.com/ee/administration/instance_limits.html ~backend - Base foundation for Custom Fields widget ~backend - Routes, settings nav updates, .. for work item settings area ~frontend - Create a new custom field -`Create field` button ~frontend - Field Type: String , length limit: `TBD`, not required - Field name input ~frontend - Save field ~frontend - Query a list of available work item types ~backend - Select to which work item types the custom field should be added to ~frontend - Enforce a limit of `10` custom fields that belong to each work item types. ~backend {+ proposed, need to validate +} - GraphQL mutation to create string field type ~backend - Validate and save to DB (sanitize, mitigate attack vector, enforce max string length of `TBD` and field name limit of `TBD` characters) ~backend {+ UX Decision +} - Field Type: Select - Field name input ~frontend - Add field option value button ~frontend - Add field option value(s) ~frontend - Reorder option value(s) ~frontend - Query a list of available work item types ~backend - Select to which work item types the custom field should be added to ~frontend - GraphQL mutation to create select field type ~backend - Validate and save to DB (sanitize, mitigate attack vector, enforce max option value limit length of `TBD` characters and field name limit of `TBD` characters) - Field Type: Number - Field name input ~frontend - Query a list of available work item types ~backend - Select to which work item types the custom field should be added to ~frontend - GraphQL mutation to create number field type ~backend - Validate and save to DB (sanitize, mitigate attack vector, enforce max number limit length of `TBD` and field name limit of `TBD` characters, support whole and fractional numbers positive and negative numbers. 0 is allowed. These will likely be used in the future as inputs for "formula computed field values") ~backend - View list of all custom fields in a namespace - GraphQL query to get custom fields ~backend - Pagination for custom fields list ~backend - Display listed custom fields ~frontend - Edit a custom field - UI to initiate editing a custom field ~frontend - Update the field name ~frontend - Update field option values ~frontend - Query to return the count of impacted work items - Double confirmation for updates where the field name or option values are renamed or deleted and display the count of impacted work items. - GraphQL mutation to update the custom field - Display count of work items where the field is present and has a set value within the custom field list view ~frontend - Navigate to `Settings > Work Items > Types` - Query to list available types within the namespace ~backend - List available types ~frontend - UX to edit available type ~frontend - List configured custom fields ~frontend - Edit custom field workflow from within work item type configuration view ~frontend (same double confirmations highlighting this will update the field for all work items using the field) - Create new custom field workflow from within the work item type configuration view ~frontend - Add existing custom field to work item type ~frontend - Delete a custom field (should we do archive instead of delete to be less destructive? - Mutation to delete custom field ~backend - Button to delete custom field ~frontend - Double confirmation warning (typing something in is required) displaying the destructive action and count of work items that would lose this field and current values with no way to recover) - Display custom fields in work item creation views - Query to get custom fields widget ~backend - Display custom fields widget + input validation ~frontend - Create mutation supports setting custom field values in the payload ~backend. - Display custom fields in work item detail views - Query supports returning custom fields ~backend - Render custom fields widget ~frontend - Edit custom fields within the custom fields widget ~frontend - Custom field updates are captured in system notes ~frontend ~backend - Mutation supports setting custom field values in the payload ~backend - Subscription to update custom field values in real-time ~backend ~frontend - Filter by custom fields - ~blocked by https://gitlab.com/groups/gitlab-org/-/epics/9937+ because it will be extra effort to add support for dynamically querying available custom fields in every view with a filter bar. - Extra work, but not too much, to add it to both boards and lists. Mostly frontend. {+ further investigation required +} 3 - Token for select field ~backend ~frontend - Filter on values of select field (=, !=, ||, ) ~backend ~frontend - Support for recently used ~backend ~frontend - Custom field settings and the field library cascade down to all namespaces, but are not editable unless you have `Maintainer+` permission in the root group. ~backend ~frontend - Updates to custom field values trigger notifications and webhook events Additional scope may be included depending on feedback from ~UX on some outstanding decisions (https://gitlab.com/gitlab-org/gitlab/-/issues/472640#decision-outstanding) </details> ### https://gitlab.com/groups/gitlab-org/-/epics/16332+ * Can create custom fields for all basic types: select (single, multiple), text, numeric, date * Can define which item types use which custom fields * Can update custom fields via quick action * Full API support for updating custom fields ### https://gitlab.com/groups/gitlab-org/-/epics/16333+ * Can create custom fields to show values generated from other fields * Can create custom fields tied to GitLab objects (e.g. select field whose values are project members) ### https://gitlab.com/groups/gitlab-org/-/epics/16335+ * Can create a custom dataset (e.g. equipment) * Can create custom fields tied to custom datasets (e.g. select field whose values are equipment) * Can import data into a custom dataset * Can update data in a custom dataset from the UI ### Potential iteration: Centralized custom fields * Can manage custom fields from a centralized library (in addition to per item type) * Additional admin or group controls over custom field use  *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.*

epic