Admin Control To Disable Custom Flows

What does this MR do and why?

This MR adds a setting to control AI catalog custom flows at the instance or top-level group level. When custom flows are disabled, they become inaccessible to users. Database changes for this setting are included in this MR.

Current state: The setting defaults to true, so there is no impact on existing custom flows. Additionally, there is no UI for this setting yet, so users cannot toggle it from the frontend. See the verification section below for testing instructions.

References

Issue - #594615 (closed)

MR for DB changes - !231887 (merged)

Screenshots or screen recordings

Before	After

How to set up and validate locally

Prerequisites

TOKEN="<personal-access-token-of-owner-user-of-TLG>"
BASE_URL="http://gdk.test:3000"

Step 1: Check TLG Setting

Verify the default state in Rails console:

top_level_group = Group.find_by_full_path('gitlab-duo')
top_level_group.namespace_settings.duo_custom_flows_enabled # => true (default)

Step 2: Disable Custom Flows via API

curl --request PUT \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --header "Content-Type: application/json" \
  --data '{ "duo_custom_flows_availability": false }' \
  "$BASE_URL/api/v4/groups/gitlab-duo"

Verify the cascade in Rails console:

top_level_group.reload.namespace_settings.reload.duo_custom_flows_enabled # => false

Check the audit log at GitLab Duo > Secure > Audit Events to confirm the change was recorded. Re-enabling the setting will trigger an additional audit event.

Step 3: Verify Custom Flows Are Disabled

Navigate to Automate > Flows:

• Enabled tab: Custom flows should not appear here
• Managed tab: Custom flows created in the project are still visible
• Custom flow details page: Users cannot perform actions on disabled flows (Only then can report the flow).
• Known issue: The "Enable" and "New Flow" buttons remain visible but non-functional (error on click). Frontend changes needed to hide these buttons

Screenshots

Step 4: Verify Execution is Blocked

Existing custom flows cannot be executed via @mention or assignment to issues/MRs.

Screenshots

Step 5: Disable Custom Flows at Instance Level

Disable the instance-level setting via API:

curl --request PUT \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --header "Content-Type: application/json" \
  --data '{ "duo_custom_flows_availability": false }' \
  "$BASE_URL/api/v4/application/settings"

Restart the Rails console to ensure the application changes are fully loaded:

cs = Gitlab::CurrentSettings.current_application_settings
cs.duo_custom_flows_enabled # => false

Verify the change in the audit log at Admin > Monitor > Audit Events.

Screenshots

Step 6: Verify Cascade Lock Behavior

Once the instance-level setting is disabled, group-level settings cannot be changed. Attempting to enable the setting at the group level will return an error:

curl --request PUT \
  --header "PRIVATE-TOKEN: $TOKEN" \
  --header "Content-Type: application/json" \
  --data '{ "duo_custom_flows_availability": true }' \
  "$BASE_URL/api/v4/groups/gitlab-duo"

Important: Even if custom flows are enabled at the top-level group, they will not be accessible if disabled at the instance level. The instance-level setting takes precedence and locks all descendant namespaces.

Testing Notes

• Use an owner or maintainer account for testing
• Do not test with the root user

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 #594615 (closed)