[UX] Custom fields design - MVC1
Design for custom fields will account for custom work item types as well as custom data tables to consider the entire vision for customization in Plan objects.
All work is currently WIP and subject to change.
First MVC: &14904 (closed) Background on approach: #472640 (closed)
🖱 Prototype
View prototype (limited interactions, must use hotspots)
📼 Design walkthrough
(design as of 2024-08-27)
7:19 MVC1 - Configuring custom fields
16:30 MVC1 - Using custom fields from detail view
18:49 MVC1 - Using custom fields in list/board views
Definitions
Custom type: A work item type which can be modified or extended by the user. All work item types may be "custom types", meaning that while users will start with default types "issues", "epics", and "tasks" those types can be edited or removed. Example: Bug, Story
Custom field: A user-defined field (widget) to be used within work item types. Custom fields are defined as a name and field type, and recorded as a value based on the field type, i.e. a type text will be saved to a work item with text value. Example: Company ID, Cost Center, Priority.
GitLab field: A field (widget) defined by GitLab which can be used on a work item type, but whose basic details are controlled by the application and not the user. Example: Assignee, Labels, Milestone
Custom object: A user-defined data table representing non-trackable objects, i.e. objects whose lifecycle is not tracked in GitLab. Custom objects can be used as part of custom fields, but could also be used outside of work items. Example: Products, Cost centers
GitLab object: An object that is defined within GitLab, which may have user-generated records, that can be used within custom fields. Example: Groups, Members, Work items
MVC1 Scope
- Limit configuring custom fields to root namespaces
- Support the ability to map custom fields to default work item types
- Initial custom field types: Select field, number, text input
- Filtering: Yes, but only for field types that make sense (e.g. select field type would allow filtering based on option value, but for text inputs, there is nothing to filter on)
- Cascading: Custom fields and field <> work item type mappings will cascade to children namespaces. These will be visible in child namespace work item configuration screens, but will only be editable if you have the appropriate permissions in the root namespace.
- Updating a custom field on a work item will add a system note on that work item.
- Moving:
- Moving a single work item (or bulk move) to a different namespace hierarchy will remove all custom fields from the current namespace hierarchy. In the UI, handle as a destructive action
- Moving a subnamespace to a different namespace hierarchy will remove all custom fields and values from all work items in that namespace and below. In the UI, handle as a destructive action
- Emphasize in the UI: Changes made to existing custom fields (e.g. Renaming a select field's option name, deleting an option, deleting a custom field) is a potentially destructive action for all work item types that use the custom field and have values already defined. Show a double confirmation for destructive actions, including the count of work items that the change would impact.
- Changing types: The same behavior as moving, including warnings about destructive side effects of potential data loss.
- Archiving or deleting custom fields, including warnings about descrutive side effects of data loss (not applicable if we opt for archiving).
- Notifications and webhooks (stretch)
Prior exploration
**Relationship map:** https://www.figma.com/board/zDjx92EZkoGsOvJ1A9hN8j/Customization-in-Plan-Objects?node-id=0-1&t=Y7TVIa7XpEXN6Hhq-0