[Spike] Allow customizable Service Desk bot name
This is a research spike into the best technical solution to accomplish #7529 (closed).
Criteria
-
Possible solutions have been collected -
Advantages and disadvantages of each discussed and detailed in description -
Solution chosen by vote -
Solution investigated further and detailed in description of #7529 (closed)
Background
When the customer of a Service Desk user emails their Service Desk address they receive an automated reply from the GitLab Support Bot, which authors an issue and subsequent replies on the customer's behalf. This is sub-optimal because the customer has no relationship with GitLab, expecting instead an email from the user's company instead.
The proposal is to allow the user to enter a name that overrides that of the GitLab support bot when it interacts with their customers.
#7529 (comment 246212160))
Proposed Solutions (from:1. Override the GitLab Support bot name
Overrides the name of the existing Support Bot when emailing the client and authoring issues/comments.
Pros:
-
service_desk_settings
introduced in !19515 (merged) already, could hold the setting - Relatively simple to implement a first iteration
Cons
- Decreases code maintainability, requires a lot of checks on author name when rendering lists of issues.
- Performance degradation when listing issues outside project context, joining project &
service_desk_settings
.
2. Override Support bot name only in email response
Overrides the name of the existing Support Bot when emailing the client, GitLab Support Bot authors issues/comments.
Pros:
-
service_desk_settings
introduced in !19515 (merged) already, could hold the setting. - Very simple to fully implement.
- Avoids any performance degredation in other areas of the application.
Cons
- Customer sees the name of the bot but the client never does, other than when changing the name.
3. Provide project-level support bots
A single, optional support bot per project that can override the existing, default one.
Pros:
-
bot_type: 'support'
user, recognisable authorship by bot vs human.
Cons:
- Knock on effects for other parts of the codebase; issues, notifications etc. Anywhere the support bot currently operates.
4. Allow designating a project member
A user of the project can be designated as the support bot. Emails are sent and issues/comments are authored in their name.
Pros:
- Maintains existing support bot behaviour as-is, augments with optional behaviour.
- Existing authorship logic is maintained throughout the rest of the application.
Cons:
- Breaks the expectation that author will have
bot_type
. - User could leave project, causing unexpected behaviour when SD falls back to GitLab support bot.
- Customers can author issues and comments as another (human) user.
5. Create a non-login user
As (3) but the user is created on-demand and cannot be 'logged in' as a person.
Pros:
- Avoids the side effects for other parts of the application that (2) would introduce by maintaining authorship logic.
Cons:
- Service Desk would have to manage the creation and deletion of a user 'behind the scenes'.
- Unexpected/unwanted user created in the client's group.
- User may be deleted, causing unexpected behaviour.
6. Allow to customize email sent by service desk
As (1) instead of just overriding the email user we could also customize the body and subject.
Pros:
-
service_desk_settings
introduced in !19515 (merged) already, could hold the setting - The email description could have details about what is happening and what are the next steps. User would know
he is reaching the service desk from the desired company. Service desk users could also give additional information in the email like SLA etc. - Simple to implement
Cons
- The following emails would come from GitLab users that make comments on service desk issues which could be confusing, but could also be specified in the first email description.