2019-09-04 21:01:54 +05:30
|
|
|
---
|
|
|
|
|
type: howto, reference
|
|
|
|
|
---
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
# Email from GitLab **(STARTER ONLY)**
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
GitLab provides a simple tool to administrators for emailing all users, or users of
|
|
|
|
|
a chosen group or project, right from the admin area. Users will receive the email
|
|
|
|
|
at their primary email address.
|
2019-07-31 22:56:46 +05:30
|
|
|
|
|
|
|
|
## Use-cases
|
|
|
|
|
|
|
|
|
|
- Notify your users about a new project, a new feature, or a new product launch.
|
|
|
|
|
- Notify your users about a new deployment, or that will be downtime expected
|
|
|
|
|
for a particular reason.
|
|
|
|
|
|
|
|
|
|
## Sending emails to users from within GitLab
|
|
|
|
|
|
|
|
|
|
1. Go to the admin area using the wrench icon in the top right corner and
|
|
|
|
|
navigate to **Overview > Users > Send email to users**.
|
|
|
|
|
|
2019-10-12 21:52:04 +05:30
|
|
|
|
2019-07-31 22:56:46 +05:30
|
|
|
|
|
|
|
|
1. Compose an email and choose where it will be sent (all users or users of a
|
|
|
|
|
chosen group or project):
|
|
|
|
|
|
2019-10-12 21:52:04 +05:30
|
|
|
|
2019-07-31 22:56:46 +05:30
|
|
|
|
|
|
|
|
## Unsubscribing from emails
|
|
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
Users can choose to unsubscribe from receiving emails from GitLab by following
|
|
|
|
|
the unsubscribe link in the email. Unsubscribing is unauthenticated in order
|
|
|
|
|
to keep this feature simple.
|
2019-07-31 22:56:46 +05:30
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
On unsubscribe, users will receive an email notification that unsubscribe happened.
|
2019-07-31 22:56:46 +05:30
|
|
|
The endpoint that provides the unsubscribe option is rate-limited.
|
|
|
|
|
|
2019-09-04 21:01:54 +05:30
|
|
|
<!-- ## Troubleshooting
|
|
|
|
|
|
|
|
|
|
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
|
|
|
|
one might have when setting this up, or when something is changed, or on upgrading, it's
|
|
|
|
|
important to describe those, too. Think of things that may go wrong and include them here.
|
|
|
|
|
This is important to minimize requests for support, and to avoid doc comments with
|
|
|
|
|
questions that you know someone might ask.
|
|
|
|
|
|
|
|
|
|
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
|
|
|
|
If you have none to add when creating a doc, leave this section in place
|
|
|
|
|
but commented out to help encourage others to add to it in the future. -->
|
