Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 43,817
    • Issues 43,817
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,444
    • Merge requests 1,444
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #323404
Closed
Open
Created Mar 03, 2021 by Brett Walker@digitalmokshaDeveloper5 of 18 tasks completed5/18 tasks

Add support for default issue types

Why are we doing this work

This is a step to supporting customizable issues, as outlined in Customizable Issue Types and Extensible Issues

We want to add support for default issue types, in preparation for adding the ability for users to create their own.

Currently proposed types:

  • Feature
  • Defect
  • Enhancement
  • Maintenance
  • Incident (system default)
  • Issue (system default)
  • Test Case (system default)
  • Requirement (system default)

Details

  • Currently supported are Issue and Incident types, stored directly in the issue table. Issue types will now need to be stored in a separate table to support adding new types.

  • Issue type definitions will be attached at the group level. For this round, we will only support them being defined at the uppermost group / namespace.

  • groups will have a checkbox in their settings allowing them decide if they want to use the new default/custom types or stick with just Issue and Incident

Open Questions

  • how is the issue type list to be sorted? Should the UI dropdown be sorted in alphabetical order (Bug, Enhancement, Feature, Incident, Issue, Tech Debt, Test Case), or by some other metric?
    • Answer: Alphabetical is fine for now.

Relevant links

Non-functional requirements

  • Documentation:
  • Feature flag:
  • Performance:
  • Testing:
  • Usage metrics: See below

Usage Metrics

When an issue type other than a system default is selected by the user during issue creation, track the number of unique users setting a non-system default issue type:

- name: g_project_management_custom_issue_type_set
  category: issue_edit
  redis_slot: project_management
  aggregation: daily

Event description YML attributes:

---
key_path: redis_hll_counters.issue_edit.g_project_management_custom_issue_type_set
description: Monthly active users that set a customizable type on an issue.
product_section: dev
product_stage: plan
product_group: group::project management
product_category: issue_tracking
value_type: number
status: data_available
time_frame: 28d
data_source: redis_hll
distribution:
- ce
- ee
tier:
- free
- premium
- ultimate

Note: This will extend to GitLab Premium as well when users are able to customize their types of issues.

Implementation plan

backend

  • create new table to house issue types (#323279 (closed))
  • add/enhance queries for the available issue types (only Group or both Project and Group) for use by the frontend
  • provide new on/off setting on Group that controls how types are managed
  • add collection of metrics for various issue types in use
  • review project import/export characteristics (#327284)
  • TBD

frontend

  • refactor issues list page from Haml to Vue so we can use GlFilteredSearch for the search bar (#322755 (closed)) — the refactor is also necessary so we can do OR/multi-select search bar filtering in #23532
  • add default issue types to search bar filter on issues list page (dropdowns should be able to query available issue types from the backend) (#268152 (closed))
  • [-] refactor new issue page from Haml to Vue to reduce current and future tech debt, and make future code changes easier (#247960) We are planning on redesigning the issue page and using that as the basis for the new create page. Don't want to delay this issue because of this, and adding this field shouldn't add a significant amount of debt
  • add default issue types to issue type select input on new issue page
  • add checkbox in Group settings to turn on/off use of custom types on a per type basis
  • display correct icon for each issue type on: issues list page, milestone report, iteration report, boards, related issues + where else?
  • TBD

Pricing Tier

  • GitLab Core given our desire to have base default issue types available in this tier (&3354). Customizable issue types will be in GitLab Premium

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.

Edited Apr 13, 2022 by Gabe Weaver
Assignee
Assign to
Time tracking