Discovery: bot member for Suggested Solution (was: Auto Remediation)
Problem to solve
In the auto-remediation MVC user research (#36500 (closed)), we found users are not comfortable with being the author of the auto-created
merge request. There isn't currently a bot or neutral member/user we could use as an alternative.
Intended users
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
Further details
Based on an MVC proposal for a bot (#36500 (comment 260858531)), this discovery looked into the 1) engineering/implementation requirements, 2) security concerns using a bot
member, 3) UX with using bot
.
Proposal
Consider adding a "bot" user to Ultimate tier instance, called GitLab-Security-Bot
. This user would be the author of the auto-created merge requests.
Bot overview |
---|
Use case for auto-remediation #36500 (closed):
Discovery review and findings:
- Learn about our existing “bots” functionality
GitLab Support Bot (Service Desk)
and/orGitLab Alert Bot
- How are they created?
-
#10159 (closed) - Bot is added on instance-level. It's
User
. From the backend side of things bot can be called byUser.security_bot
. It creates aUser
entity in the database. Bot isn't a member of any project, it is visible only from Users tab in the Admin panel. Such Bot doesn’t take a seat in the License plan. Bot has a User profile, its username can be used in queries by MR’s author name.
-
#10159 (closed) - Bot is added on instance-level. It's
- Are they out of the box?
- Adding a new bot is quite simple: add new bot to ee/app/models/ee/user_bot_type_enums.rb and follow example for Alert bot
- How do they work for saas vs on-premise?
- It works in the same manner.
- Are the current bots visible members?
- Yes, for example:
support bot
is visible in the list and the functionality is shown like others, but the user is unable to take actions (goes to 404 page when executed). issue created: #208793 (closed). For theGitLab Security Bot
we can display the user to surface documentation (actions not visible in UI)
- Yes, for example:
- How we can add Bot as an MR author?
- How to assign Bot as an author of MR?
- Proposed workflow:
- Pipeline is successfully finished.
- We check if available solutions are available on the backend.
- If there are solutions available, we create an MR with the help of
VulnerabilityFeedback::CreateService
and we put security_bot as an author of the MR. (now this service use current user as an author)
- We can reuse this code https://gitlab.com/gitlab-org/gitlab/-/blob/197808d37204cc16886e3404e47205555a24335c/ee/app/services/vulnerability_feedback/create_service.rb#L75 to create an MR automatically. We just need to change
current_user
tobot
.
- Proposed workflow:
- How to assign Bot as an author of MR?
- What might we be able to reuse?
- How do make sure the extra member doesn't add a seat?
- These bots ain't members, they are "users" on instance level and are operated from inside of GitLab. That means that we can use those bots for any projects.
- How are they created?
- For the use case of auto-remediation MVC:
- Can we have this bot as a member that’s out of the box? Consider UX when the member is deactivated and the relationship with the opt-in of
auto-create merge request
- UX for findability and discovery of the bot
- Bot member profile page activity - what/when activity will be shown
- Identify permissions: who can setup/deactivate feature/bot? Is the bot member a developer?
- Can we have this bot as a member that’s out of the box? Consider UX when the member is deactivated and the relationship with the opt-in of
- What are the security concerns?
- Will sync with our appsec team with proposed prototype to review and analyze for security issues
- Learn about any use cases that may follow
other considerations:
- Have a link to the Bot's documentation page in the bot's profile that explains the account and how to manage it and what it does
- For opened merge request, having it automatically assigned could be helpful and/or that aligns to an orgs workflow
- Add activity or note that "This MR was generated automatically by GitLab" or similar to bot action occurs
- If we have built-in user accounts, these accounts should have something more than a gravatar and a "Bot" name, there should be some design treatment that clearly denotes this account as a system account.
What does success look like, and how can we measure that?
- In testing our MVC: #36500 (closed), we found users said they would create a new member to
auto-create the merge requests
. Does the user use theGitLab-Security-Bot
instead? - Does the user understand the bot is a member and understands it's role (author of merge request)?
- Does the user know how to setup the feature?
What is the type of buyer?
Discovery Conclusion
Discovery outcome: UX/Engineering recommends the proposed solution to introduce a GitLab-Security-Bot
user in #36500 (closed).
Engineering notes
How to create a bot?
Adding a new bot is quite simple: you need to add bot to bots_hash and create a class method for User model. Example of adding Alert bot: !10460 (diffs)
Is Bot a User?
Yes, from the code bot can be called by User.security_bot
. It creates a User entity in the database. Bot isn't a member of any project, it is visible only from Users tab in the Admin panel. Such Bot doesn’t take a seat in License plan. Bot has a User profile, its username can be used in queries by MR’s author name.
How to assign Bot as an author of MR?
Proposed workflow:
Pipeline is successfully finished.
We check if available solutions are available on the backend.
If there are solutions available, we create an MR with the help of VulnerabilityFeedback::CreateService and we put security_bot as an author of the MR. (now this service use current user as an author)
We can reuse this code https://gitlab.com/gitlab-org/gitlab/-/blob/197808d37204cc16886e3404e47205555a24335c/ee/app/services/vulnerability_feedback/create_service.rb#L75 to create an MR automatically. We just need to change current_user
to bot
.
UX notes
Ongoing and next step efforts:
- Displaying projects that #210519 is configured in the profile. This is to help the user understand what projects are affected by the system bot. (since the profile will span across different projects)
- UX bug: removing front-end actions available to bots in admin > user, related issue #195309 (closed). The
Security Bot
will be seen in the admin - Work closely with the technical writing team to ensure clear documentation. Additionally, evaluate as new tasks are added to the bot.
- In #36503 and any other system tasks the bot may adopt: evaluate with app sec team to ensure alignment and identify security concerns.
- Look into creating a custom bot emoji to reinforce it’s a bot (key UXR question: do users understand this is a system, not their org user)
- Visual design: 1) create an avatar for the security bot, and 2) align profile with other bots for consistency and better communication to the user that it’s a system bot (#210523). Example: that https://gitlab.com/support-bot does not include links to documentation or visually anything to distinguish it as a system bot.
User research questions:
- What is the user’s perception of the bot?
- Does the user understand that the user is a GitLab system feature?
- If the user wants to learn more, what do they do?
- Is the documentation accessible and clear?