Starred items > Persist starred items

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Proposal

  • Create a mechanism to store starred items. Starred items can be:
    • A first-class GitLab object (e.g. a work item, merge request, pipeline, vulnerability, etc)
    • A link to a specific page in the product (e.g. a board view, a specific settings page)
  • We need to capture the following information to support our use cases:
    • A reference to the starred item (e.g. as a foreign key, a URL, etc)
    • The user that starred the item
    • When the item was starred
  • This could extend the existing "starred projects" system, but it doesn't have to

Technical Approach

Based on team discussion, we will implement a hybrid approach:

Phase 1: Many-table pattern for first-class objects

  • Implement dedicated tables for high-priority starrable objects (work items (issues) and MRs)
  • Follow existing GitLab patterns with proper foreign key constraints and dependent: :destroy associations
  • Each object type gets its own join table (e.g., users_star_issues, users_star_merge_requests)
  • This provides robust data integrity and enables rich features like filtering by object type

Phase 2: URL-based fallback for everything else

  • Generic URL storage for pages/views that aren't first-class database objects
  • Supports bookmarking filtered views, settings pages, and other dynamic content
  • Store URL + title for basic bookmark functionality
  • We can default to the document.title but should also allow to edit it, so a user can give short custom names lie "my team board".

Priority Objects (based on user research)

Most commonly requested bookmarks from research:

  1. List views: MR lists, issue lists, pipeline lists
  2. Long-running items: Issues, epics, MRs
  3. Navigation targets: Issue boards, groups, CI/CD catalogue
  4. External resources: Links to Jira, documentation, wiki pages

Implementation Strategy

  • Build the system to allow other teams to opt into starring for their domain objects
  • Start with issues and MRs as the first implementation
  • Design the architecture to be extensible and well documented, so other teams can extend it for their objects without requiring our team to maintain every object type
  • Consider preserving "orphaned" stars when objects are deleted (for user context) rather than auto-deletion

Database Considerations

  • Avoid extending the existing users_star_projects system to prevent disruption.
  • New models will be built from scratch for maximum flexibility.
  • Each starrable object type requires schema changes and homepage integration updates.
Edited by 🤖 GitLab Bot 🤖