Design: Security Attributes

Problem to solve

See Security Attributes/Context Filtering (&18010)

Proposal

Resources:

  • 🎨 Design File
  • 🕹️ Prototype
    • Note: The link destinations between group and project levels do not accurately reflect the actual behavior (actual landing page will differ).

Requirements (WIP)

Here's the text with all occurrences of "label" and "labels" replaced with "attribute" and "attributes":

Requirements (WIP)

  1. Management & Permissions
    1. Scope & Hierarchy
      1. Security attribute categories and attributes can be managed at any group or subgroup level
      2. All categories and attributes are automatically synced and shared across all groups and subgroups
      3. Projects can only apply or remove existing attributes—they cannot create or edit categories or attributes
    2. User Permissions
      1. Attribute management actions are only visible to users with appropriate permissions
      2. Permission levels align with the category types (read-only, partial-edit, full-edit)
  2. Attribute Category Behavior
    1. Category Types — Security attributes are organized into three category types with different permission levels:
    2. Read-only: Created by GitLab system. Categories and attributes cannot be edited or deleted by users
    3. Partial-edit: Created by GitLab system. Categories cannot be deleted, but individual attributes within the category can be edited
    4. Full-edit: Created by users. Both categories and attributes can be edited and deleted (requires appropriate permissions)
    5. Selection Behavior
      1. Each category must specify whether it allows single selection or multiple selection of attributes
      2. Selection type is set during category creation and cannot be changed afterward to avoid data migration complexity
  3. Creation & Editing Workflow
    1. Category Creation
      1. At least one attribute must be added when creating a new category
      2. Empty categories (categories without attributes) are not permitted
    2. Save Behavior
      1. All changes to categories and attributes require manual saving (no auto-save functionality)
      2. Display a confirmation toast message when changes are successfully saved
      3. If a user navigates away from a category form with unsaved changes, prompt them to either continue editing or discard changes
  4. Attribute Application
    1. Where Attributes Can Be Applied Security attributes can be applied to and removed from projects in these locations:
      1. Security Inventory (page)
      2. Project → Security Configuration (page)
  5. User Experience
    1. Navigation & Context
      1. Attribute counts should only display for projects within the user's current group/subgroup context
      2. Users should not see counts for projects outside their current scope
    2. Design Consistency
      1. Attribute selection UI must align with existing GitLab patterns for regular labels
      2. Use icons and tooltips to clarify selection behavior and restrictions
Edited by Michael Fangman