GitLab Incubation Engineering - Latest, 20 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Incubation Engineering - Service Desk - Update 3

Description

This is the third update video for the GitLab Service Desk Single Engineer Group. Service Desk is now part of the company vision. Marc showcases the functionality for the foundation work for customizable email addresses and also teases the current work around custom email address verification. Additionally he presents a solution to obfuscate private data in Service Desk issues based on the user role in a project.

Update-Issue: https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/7
Custom email foundation Merge Request: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108017
Tasks for customizable email addresses proposal: https://gitlab.com/gitlab-org/gitlab/-/issues/329990#proposal
Obfuscate issue email participants Merge Request: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108901

You can find all resources on the Service Desk SEG handbook page :
https://about.gitlab.com/handbook/engineering/incubation/service-desk/

Please subscribe to this GitLab issue if you would like to receive notifications for all future updates:
https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/3

Additionally you may have a look at the feature exploration issue:
https://gitlab.com/gitlab-org/incubation-engineering/service-desk/meta/-/issues/2

If you want to learn more about Incubation Engineering at GitLab, please visit
https://about.gitlab.com/handbook/engineering/incubation/

Chapters
0:00 Intro
0:14 Service Desk in company vision
0:28 Custom email address foundation
1:58 Custom email address verification
4:08 Obfuscate issue email participants
5:46 Outro

A

Hi, this is update number three for the gitlab service desk single engineer group.

A

Yeah so first things first um service desk is now part of our company vision. You can see it here on our vision, page in the handbook and I think that's a very good sign, because service desk has a lot of potential, so the merge request for custom email address Foundation.

A

This adds the ability to gitlab to send service test emails via custom SMTP settings only behind a feature flag and from the console, but once you enable this feature flag and have settings enabled and git level will send Services emails for that specific project via the provided credentials. It has now all approvals and is ready to be merged. I want to give you a short overview of what actually happens there. We have a service desk here and default.

A

Behavior would be in that it will be delivered in this deaf environment by letter opener, but normally just our your normal configured email address.

A

We should see that via the default settings, so in this case in the development environment, this is an example at example.con address. So now I go into the console. I have this setting.

A

um This is the email address, I will use fat juice, official gmail.com, and it should also use this as the from address, but it should also send via the SMTP settings I provided here. Let's name it the feature flag and give it another. Try.

A

And this is the notification I received it's from fat juice, official gmail.com delivered to my account and mailed by gmail.com. So this worked via those SMTP settings.

A

Yes, I started work on custom email, address, verification which is part two of getting custom, email addresses into gitlab service desk, and what this should do is it triggers a verification process that disables the custom email if it was active before, because right now we have new settings and we need to verify them first, it generates a 12 character, verification token that we use to verify ownership and it sends that token to the custom email address with a verify sub addressing part.

A

So we can also check whether sub addressing works, because we need that later on and we send that via the provided SMTP settings. So we can check a bunch of things that work. Additionally, we send notification emails to our project owners and the person who triggered the verification before that we set up a email forwarding from our custom email address to the service desk email address. Once that's in our service desk mailbox, we will pick that up check the verification.

A

Token check whether the from headers are intact and then say: hey this email address was verified successfully.

A

This will also send an additional email to our project owners and the user triggered the verification and then, after that, you could enable the setting and use that for all service desk email addresses. So this is also a work in progress. The merge request will follow in a couple of days and I just wanted to show you how that works.

A

So here's the email. This is the mailbox for veggiesofficial gmail.com. This is the email you can see. It was sent via the SMTP settings of that email address and we have this sub addressing part here and it worked quite fine, and we have this verification code here that we can later use to verify the ownership. Additionally, we notified the project owner. This is this email and the person who triggers the process. It's this email, let's just play sort of text, but they will receive an email, so they know hey.

A

This is there's a verification going on so the last thing: obfuscate issue, email participant based on member role. At gitlab we take user privacy seriously, so we want to ensure that only users with the corresponding roles have access to private data. That's also true for service desk, so as a site gig, and to get more into the code base and learn about internal things. I started to work on obfuscating issue, email participants and the idea is to kind of redact or transform the email addresses of those participants and the issue your email address.

A

If you do not have at least the report or role for a project, that's especially useful if you have a public service desk, for instance, or service desk issues that are not confidential anymore, for some reason. So to give you an idea of what that looks like I'm logged in now, but I don't have a role in that specific project. It's public and the service desk issues aren't confidential, so I can see them per convention, but I cannot see the email addresses in the list page and that's also true for the detail.

A

Page and the email addresses have been obfuscated here. Even if I had a role in that project- and it was, for instance, the guest role I could not see the email addresses I need to minimum the report available to access the private data here. So we had a really good collaboration on this one and came up with a good working pattern, and we also started work on getting this into our design ecosystem guidelines, which is really cool.

A

This merch request is still in review, but I'm really looking forward to having this merged, maybe in a couple of days. So that's it for today feel free to leave a comment on the video on the update issue. I link everything in the description and see you soon take care.