Enforce type visibility in BuildService#resolve_work_item_type

Marc Saleiko (OOO - back on 2026-08-10)requested to merge
591372-build-service-visibility-enforcement into master

What does this MR do and why?

Adds server-side enforcement for work item type visibility controls in Issues::BuildService#resolve_work_item_type. When a type is disabled via namespace visibility controls, archived, or context-mismatched (e.g. Epic in a project), the service now rejects it and returns an error instead of silently accepting it.

Previously, the enabled field on WorkItemType was advisory only -- the frontend used it to hide UI elements, but the backend did not enforce it during creation. This MR closes that gap.

Why enabled? instead of can_user_create_items?

The natural fit appears to be can_user_create_items?, but that method also checks creatable?, which is false for types like test_case, requirement, and ticket that have dedicated creation flows. These types are still legitimately creatable via the legacy issue_type param and the existing create_issue_type_allowed? permission check. Adding can_user_create_items? here would break those paths.

The three checks layer cleanly:

  1. create_issue_type_allowed? -- permission gate (can this user create this type?)
  2. enabled? -- visibility gate (is this type available in this namespace?) (this MR)
  3. creatable? -- UI flow gate (does this type appear in the work item creation form?)

Import skip

The visibility check is skipped when issue.importing? is true, honouring the import contract agreed in #586188 (closed): imports should land all records and audit mismatches later, not silently drop them. Today, CSV import does not set importing = true on the issue (only Direct Transfer / file-based do) -- when that plumbing is added, this skip will apply automatically.

This is Part 2 of #591372 (closed)

Part 1 (!235290 (merged), merged) added a will_save_change_to_work_item_type_id? guard on the model-level validation so existing work items with disabled types remain editable. This MR adds the service-level enforcement for new creation.

References

How to set up and validate locally

  1. Enable the feature flag: Feature.enable(:work_item_configurable_types)

  2. Enable customizable type visibility for a root group via the workItemSettingsUpdate mutation

  3. Disable a type (e.g. Task) for a project via workItemAvailabilityToggle

  4. Try to create a work item of that type in the project:

    mutation { workItemCreate(input: { namespacePath: "" title: "test" workItemTypeId: "gid://gitlab/WorkItems::Type/5" }) { workItem { id } errors } }

  5. Expect an error: the type should be rejected and the work item should not be created

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.

Edited by Marc Saleiko (OOO - back on 2026-08-10)

Merge request reports