Breakdown unit primitives per user interface and frontend checkes
Problem
In Use Vertex AI proxy endpoints in VertexAI::Client (!153215 - merged), we've introduced a bunch of unit primitives in ee/config/cloud_connector/access_data.yml
. These should be reorganized per user interface.
For example, if "explain vulnerability" feature appears in Duo Chat and Vulnerability UI dashboard, access_data.yml
would be:
user_interfaces: # ex. `services`
duo_chat: # Duo Chat user interface
backend: 'gitlab-ai-gateway'
bundled_with:
duo_pro:
unit_primitives:
- duo_chat
- documentation_search
duo_enterprise:
unit_primitives:
- explain_vulnerability
explain_vulnerability_in_vulnerability_dashboard: # Explain Vulnerability feature in Vulnerability dashboard
backend: 'gitlab-ai-gateway'
bundled_with:
duo_enterprise:
unit_primitives:
- explain_vulnerability
and we need to implement a frontend checks to show the UI only while the feature has free access or when the user is assigned to add-on seat . This can be done with:
::CloudConnector::AvailableUserInterfaces.find_by_name(:explain_vulnerability_in_vulnerability_dashboard).available_for?(user) || ::CloudConnector::AvailableUserInterfaces.find_by_name(:explain_vulnerability_in_vulnerability_dashboard).free_access?
# ex. ::CloudConnector::AvailableServices. For avoiding confusion.
or this should be part of Declartive policy (e.g. GlobalPolicy):
user.can?(:explain_vulnerability_in_vulnerability_dashboard) # Check ::CloudConnector::AvailableUserInterfaces subsequently.
Note: In order to bring these features to the SM, we need to copy the configuration of the feature from access_data.yml
to https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/config/cloud_connector.yml as well.
Proposal
Among other things:
- User who has Duo Pro and attempts to use a Duo Enterprise chat feature should get the message below.
- User who has Duo Enterprise and attempts to use a Duo Enterprise chat feature should receive the chat answer to her question.
Auto generated
The following discussion from !153215 (merged) should be addressed:
-
@nmilojevic1 started a discussion: (+4 comments) We are deprecating
::CloudConnector::AccessService
, and the preferred way that will leverage configuration inaccess_data.yml
would be to usereturn ::CloudConnector::AvailableServices.find_by_name(service_name).access_token(user)
What is the
service_name
?In
access_data.yml
or CDotscloud_connector.yml
file we have:services: summarize_review: # Represents the service_name backend: 'gitlab-ai-gateway' bundled_with: duo_enterprise: unit_primitives: # Represents the unit_primitive (sub-feature) and the way how it is sold (in this case bundled with the `duo_enterprise` addon) # the `summarize_review` is also used as a scope when the jwt token is issued. # Note that one service can potentially have multiple unit_primitives/scopes - summarize_review
To be honest, the service is a little unfortunate name, but we are syncing the
CloudConnector::AvailableServices
from CDOT usingcloudConnectorAccess
query. The service is :duo_chat, the UP/scope is [:duo_chat, :documentation_search]The service_name actually presents UI/UX group. Some Unit primitives are using the same UI/UX. Example: The user can see the
duo_chat button
and open theduo_chat window
only if it can access at least one duo_chat UP.So basically with current stand-alone features, the ai service (UI/UX group) usually consists only of one unit_primitive. The duo_chat is the only exception for now.
Because of this, I would suggest renaming the unit_primitive parameter in constructor with the
service_name
. -
@shinya.maeda started a discussion:
For now, I've switched to
::CloudConnector::AvailableServices.find_by_name(:ai_gateway_proxy).access_token(user)
.We can break it down further for frontend checks in the future.
-
@nmilojevic1 started a discussion:
For DuoChat and CodeSuggestions we have these permission checks in the
ee/global_policy.rb
This way we use the same policy check in both the front end and backend. We should probably do the same here.
We do check if the UI/UX for the feature is available/visible based on the license, the cut_off_date (service is experimental/beta/has free access), enabled via group/project settings, and if a user is assigned to the proper addon seat.
::CloudConnector::AvailableServices.find_by_name(service_name).allowed_for?(user)
checks if user is assigned to the proper seat::CloudConnector::AvailableServices.find_by_name(service_name).free_access?
checks if a service is in beta/experimental state/has free accessI would expect that we do something like:
service = ::CloudConnector::AvailableServices.find_by_name(service_name) # Check if the feature is available for the given user based on seat assignment, add-on purchases return unauthorized! unless service.free_access? || service.allowed_for?(user)
All these services are experimental (have free access), as there is no cut_off_date defined in
access_data.yml
norcloud_connector.yml
for them. This does not need to be included in this MR, but it would cover permission checks, and allow us to cut off access/sending requests to AI Gateway when the features stop being an experimental feature