Loosen duoWorkflows analytics authorization; protect creditsUsed

What does this MR do and why?

The duoWorkflows analytics data (flow counts, usage stats) was only visible to users holding the read_agent_artifacts custom ability, which can only be granted through custom member roles and requires the custom roles license. That made the analytics inaccessible to most users. This MR relaxes the requirement so that any Reporter or above can see flow analytics as long as AI analytics is licensed, matching how other analytics data already works. The one exception is credit/cost consumption (creditsUsed): that stays locked down via measurement-level authorization and only shows real numbers for users who hold the read_agent_artifacts custom ability, returning null for everyone else. A small supporting fix also allows the aggregation authorization check to work for anonymous users viewing public resources. Everything here is behind the dap_impact_v1 feature flag and marked as an experimental field.

References

Related issue: https://gitlab.com/gitlab-org/gitlab/-/issues/622366

Screenshots or screen recordings

Backend-only change, no UI changes.

How to set up and validate locally

  1. Enable the feature flag in rails console: Feature.enable(:dap_impact_v1)
  2. Ensure an EE license with AI analytics and custom roles available (ai_analytics, custom_roles licensed features).
  3. As a user with Reporter access to a group, run a GraphQL query against the group's analytics { duoWorkflows { aggregated ... } } field requesting totalCount, usersCount, and creditsUsed — counts return values, creditsUsed returns nulls.
  4. Create a custom member role with the "read agent artifacts" permission and assign it to the user, then re-run the query — creditsUsed now returns real values.

Note: local ClickHouse with Duo workflow data is required for actual numbers.

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 #622366

Edited by Pavel Shutsin

Merge request reports

Loading
Loading