Issue: #583013

What does this MR do and why?

This code change adds tracking functionality to monitor how users interact with custom work item types and custom fields in GitLab.

The system now records when users create, update, or archive custom work item types, as well as when they modify which work item types are associated with custom fields. This tracking helps the product team understand feature usage patterns.

Specifically, it tracks four types of events:

1. Creating new custom work item types
2. Updating existing work item types (name or icon changes)
3. Archiving or unarchiving work item types
4. Changing which work item types use specific custom fields

The tracking includes contextual information like the user performing the action, the workspace (namespace), and the name of the item being modified. For archiving events, it also records whether the item was archived or unarchived.

The implementation includes proper safeguards - tracking only occurs when operations are successful and excludes certain edge cases like system-generated conversions. Comprehensive tests ensure the tracking works correctly across all scenarios.

This data collection will help GitLab's product team make informed decisions about improving these enterprise features based on real usage patterns.

References

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Daniyal Arshad (89a40de3) at 18 Mar 23:16

@msaleiko thanks for the discussion, just to understand the current behaviour when you say

That means the provider would return nil for the given type and so fall back to the default type which is issue.

You are referring to the checks in the build_service.rb in the set_work_item_type method. The workflow would look something like this correct?

1. User requests to create a work item of custom type X
2. Provider looks up type X, but since the namespace doesn't have the license, it's not in the cache -> returns nil
3. nil means no valid type was found, so the code silently falls back to creating a regular Issue instead
4. The user gets no error -- they just get an Issue instead of their custom type

Example:

For a type converted from Incident, base_type would be "incident". The code in build_service.rb falls through to the normal path and calls:

create_issue_type_allowed?(container, "incident")
# => can?(current_user, :create_incident, container)

If the user doesn't have :create_incident permission, this returns false, and the code falls back to:

work_item_type_provider.default_issue_type  # silently creates an Issue instead

This does seem ambiguous when the user requested a work item of incident type but ended up with an issue type without any feedback or error response.

I share the same feelings about this approach that it is not great from a UX point of view but i guess if it was like this in the past, we don't really need to change this.

Issue: #581939

What does this MR do and why?

This change improves how work item types are retrieved and displayed in the GraphQL API. Previously, the system would return work item types directly from the database, but now it routes them through a "Provider" service that ensures custom work item types (user-defined types) are properly prioritized over system defaults when they have the same functionality.

The key improvement is that when a user creates a custom work item type that replaces a built-in type (like creating a custom "Bug" type to replace the default "Issue" type), the API will now correctly show the custom version instead of the default one. This affects three main areas: the list of types a work item can be converted to, and the parent/child relationship rules in hierarchical work items.

The changes also include comprehensive tests to verify this new behavior works correctly, ensuring that custom types appear in place of system types when appropriate, and that the ordering and relationships between work item types are maintained properly.

References

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Daniyal Arshad (d9fad467) at 18 Mar 22:05

Daniyal Arshad (083f7a00) at 18 Mar 21:45

... and 341 more commits

@nicolasdular thanks for all the work on the traversal ids, the FF cleanup LGTM 🚀

However, it looks like we need to update the commit with a changelog entry for the FF removal

@mdangelo6 can you please do the maintainer review? Thanks

What does this MR do and why?

Remove use_namespace_traversal_ids_for_work_items_finder feature flag

The feature flag is now default enabled and the namespace traversal IDs path should be the standard code path. Remove the flag and all related conditional logic and tests.

Changelog: changed

References

Screenshots or screen recordings

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Addressed via this commit, added the model specs for icon_names validation

Addressed via this commit, added a test case for creating a converted type with an invalid name which returns the error

@aslota would you be able to help get this merged? The latest commit fixes the spec failure Marc mentioned but it also reset his approval.

Daniyal Arshad (d2387043) at 18 Mar 19:13

Daniyal Arshad (f260f003) at 18 Mar 17:28

@msaleiko yes im working on a fix for the failing specs and addressing the other 2 suggestions from Stefanos in the same commit

Closing this issue since MR is merged

Both items addressed and changes merged in this MR: Handle archived types (!226949 - merged)

@syarynovskyi backend changes LGTM 🚀

@mdangelo6 can you please take over the maintainer review? Thanks

What does this MR do and why?

Update Premium billing page to adapt trial flow changes

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

• Setup gdk to simulate SaaS - https://docs.gitlab.com/ee/development/ee_features.html#simulate-a-saas-instance and restart GDK
• Sign in as root. Create new group.
• In admin section update plan to be premium.
• Visit /-/billings page.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #587958