Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
84b4743475
commit
49f2ba9ed5
36 changed files with 329 additions and 128 deletions
|
|
@ -187,7 +187,7 @@ export default {
|
|||
<template #tabs-end>
|
||||
<div
|
||||
data-testid="md-header-toolbar"
|
||||
:class="{ 'gl-display-none': previewMarkdown }"
|
||||
:class="{ 'gl-display-none!': previewMarkdown }"
|
||||
class="md-header-toolbar gl-ml-auto gl-pb-3 gl-justify-content-center"
|
||||
>
|
||||
<toolbar-button
|
||||
|
|
|
|||
|
|
@ -72,7 +72,6 @@
|
|||
@include media-breakpoint-down(xs) {
|
||||
.nav-item {
|
||||
flex: 1;
|
||||
border-bottom: 1px solid $border-color;
|
||||
}
|
||||
|
||||
.gl-tab-nav-item {
|
||||
|
|
@ -84,7 +83,8 @@
|
|||
width: 100%;
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
margin-top: $gl-padding-8;
|
||||
padding-top: $gl-padding-8;
|
||||
border-top: 1px solid $border-color;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -4,8 +4,9 @@
|
|||
%h4.gl-display-flex
|
||||
= s_('GroupsNew|Import groups from another instance of GitLab')
|
||||
= link_to _('History'), history_import_bulk_imports_path, class: 'gl-link gl-ml-auto'
|
||||
.gl-alert.gl-alert-warning{ role: 'alert' }
|
||||
= sprite_icon('warning', css_class: 'gl-icon s16 gl-alert-icon gl-alert-icon-no-title')
|
||||
= render 'shared/global_alert',
|
||||
dismissible: false,
|
||||
variant: :warning do
|
||||
.gl-alert-body
|
||||
- docs_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: help_page_path('user/group/import/index.md') }
|
||||
- docs_link_end = '</a>'.html_safe
|
||||
|
|
|
|||
|
|
@ -66,6 +66,7 @@ Rails.application.routes.draw do
|
|||
end
|
||||
|
||||
Gitlab.ee do
|
||||
resources :company, only: [:new]
|
||||
resources :groups, only: [:new, :create]
|
||||
resources :projects, only: [:new, :create]
|
||||
resources :groups_projects, only: [:new, :create] do
|
||||
|
|
|
|||
|
|
@ -594,6 +594,7 @@ Sobelow
|
|||
Solargraph
|
||||
Solarized
|
||||
Sourcegraph
|
||||
spammable
|
||||
sparkline
|
||||
sparklines
|
||||
spidering
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ These features can help provide visibility into GitLab and audit what is happeni
|
|||
|
||||
These features can also help with compliance requirements:
|
||||
|
||||
- [**Email all users of a project, group, or entire server**](../tools/email.md)
|
||||
- [**Email all users of a project, group, or entire server**](../user/admin_area/email_from_gitlab.md)
|
||||
(for instances): An administrator can email groups of users based on project
|
||||
or group membership, or email everyone using the GitLab instance. These emails
|
||||
are great for scheduled maintenance or upgrades.
|
||||
|
|
|
|||
|
|
@ -10,6 +10,14 @@ Review this page for update instructions for your version. These steps
|
|||
accompany the [general steps](updating_the_geo_sites.md#general-update-steps)
|
||||
for updating Geo sites.
|
||||
|
||||
## Updating to 14.9
|
||||
|
||||
**DO NOT** update to GitLab 14.9.0.
|
||||
|
||||
We've discovered an issue with Geo's CI verification feature that may [cause job traces to be lost](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6664). This issue will be fixed in the next patch release.
|
||||
|
||||
If you have already updated to GitLab 14.9.0, you can disable the feature causing the issue by [disabling the `geo_job_artifact_replication` feature flag](../../feature_flags.md#how-to-enable-and-disable-features-behind-flags).
|
||||
|
||||
## Updating to 14.2 through 14.7
|
||||
|
||||
There is [an issue in GitLab 14.2 through 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/299819#note_822629467)
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
|
|||
- [Sync LDAP](auth/ldap/index.md)
|
||||
- [Kerberos authentication](../integration/kerberos.md)
|
||||
- See also other [authentication](../topics/authentication/index.md#gitlab-administrators) topics (for example, enforcing 2FA).
|
||||
- [Email users](../tools/email.md): Email GitLab users from GitLab.
|
||||
- [Email users](../user/admin_area/email_from_gitlab.md): Email GitLab users from GitLab.
|
||||
- [User Cohorts](../user/admin_area/user_cohorts.md): Display the monthly cohorts of new users and their activities over time.
|
||||
- [Audit events](audit_events.md): View the changes made on the GitLab server for:
|
||||
- Groups and projects.
|
||||
|
|
|
|||
|
|
@ -903,6 +903,10 @@ You can also [run cleanup on a schedule](../../user/packages/container_registry/
|
|||
|
||||
## Container Registry garbage collection
|
||||
|
||||
NOTE:
|
||||
Retention policies within your object storage provider, such as Amazon S3 Lifecycle, may prevent
|
||||
objects from being properly deleted.
|
||||
|
||||
Container Registry can use considerable amounts of disk space. To clear up
|
||||
some unused layers, the registry includes a garbage collect command.
|
||||
|
||||
|
|
|
|||
|
|
@ -183,9 +183,12 @@ Redis version >= 2.0.0? ... yes
|
|||
Checking GitLab ... Finished
|
||||
```
|
||||
|
||||
## Rebuild authorized_keys file
|
||||
## Rebuild `authorized_keys` file
|
||||
|
||||
In some case it is necessary to rebuild the `authorized_keys` file. To do this, run:
|
||||
In some cases it is necessary to rebuild the `authorized_keys` file,
|
||||
for example, if after an upgrade you receive `Permission denied (publickey)` when pushing [via SSH](../../ssh/index.md)
|
||||
and find `404 Key Not Found` errors in [the `gitlab-shell.log` file](../logs.md#gitlab-shelllog).
|
||||
To rebuild `authorized_keys`, run:
|
||||
|
||||
**Omnibus Installation**
|
||||
|
||||
|
|
|
|||
|
|
@ -1455,10 +1455,12 @@ To configure the Praefect nodes, on each one:
|
|||
### Configure Gitaly
|
||||
|
||||
The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
|
||||
requirements that are dependent on data, specifically the number of projects
|
||||
and those projects' sizes. It's recommended that a Gitaly Cluster stores
|
||||
no more than 5 TB of data on each node. Depending on your
|
||||
repository storage requirements, you may require additional Gitaly Clusters.
|
||||
requirements that are dependent on data and load.
|
||||
|
||||
NOTE:
|
||||
The Reference Architecture specs have been designed with good headroom in mind
|
||||
but for Gitaly, increased specs or additional
|
||||
Gitaly Cluster arrays may be required for notably large data sets or load.
|
||||
|
||||
Due to Gitaly having notable input and output requirements, we strongly
|
||||
recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
|
||||
|
|
|
|||
|
|
@ -1459,10 +1459,12 @@ the file of the same name on this server. If this is the first Omnibus node you
|
|||
### Configure Gitaly
|
||||
|
||||
The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
|
||||
requirements that are dependent on data, specifically the number of projects
|
||||
and those projects' sizes. It's recommended that a Gitaly Cluster stores
|
||||
no more than 5 TB of data on each node. Depending on your
|
||||
repository storage requirements, you may require additional Gitaly Clusters.
|
||||
requirements that are dependent on data and load.
|
||||
|
||||
NOTE:
|
||||
The Reference Architecture specs have been designed with good headroom in mind
|
||||
but for Gitaly, increased specs or additional
|
||||
Gitaly Cluster arrays may be required for notably large data sets or load.
|
||||
|
||||
Due to Gitaly having notable input and output requirements, we strongly
|
||||
recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
|
||||
|
|
|
|||
|
|
@ -397,11 +397,13 @@ are supported and can be added if needed.
|
|||
|
||||
## Configure Gitaly
|
||||
|
||||
[Gitaly](../gitaly/index.md) server node requirements are dependent on data,
|
||||
specifically the number of projects and those projects' sizes. It's recommended
|
||||
that a Gitaly server node stores no more than 5TB of data. Although this
|
||||
reference architecture includes a single Gitaly server node, you may require
|
||||
additional nodes depending on your repository storage requirements.
|
||||
[Gitaly](../gitaly/index.md) server node requirements are dependent on data size,
|
||||
specifically the number of projects and those projects' sizes.
|
||||
|
||||
NOTE:
|
||||
The Reference Architecture specs have been designed with good headroom in mind
|
||||
but for Gitaly, increased specs or switching to Gitaly Cluster
|
||||
may be required for notably large data sets or load.
|
||||
|
||||
Due to Gitaly having notable input and output requirements, we strongly
|
||||
recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
|
||||
|
|
|
|||
|
|
@ -1399,10 +1399,12 @@ the file of the same name on this server. If this is the first Omnibus node you
|
|||
### Configure Gitaly
|
||||
|
||||
The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
|
||||
requirements that are dependent on data, specifically the number of projects
|
||||
and those projects' sizes. It's recommended that a Gitaly Cluster stores
|
||||
no more than 5 TB of data on each node. Depending on your
|
||||
repository storage requirements, you may require additional Gitaly Clusters.
|
||||
requirements that are dependent on data and load.
|
||||
|
||||
NOTE:
|
||||
The Reference Architecture specs have been designed with good headroom in mind
|
||||
but for Gitaly, increased specs or additional
|
||||
Gitaly Cluster arrays may be required for notably large data sets or load.
|
||||
|
||||
Due to Gitaly having notable input and output requirements, we strongly
|
||||
recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
|
||||
|
|
@ -2157,6 +2159,7 @@ but with smaller performance requirements, several modifications can be consider
|
|||
- Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). This will also lead to reduced performance.
|
||||
- GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy.
|
||||
- Gitaly and Praefect: A quorum is not strictly necessary. Two Gitaly nodes and two Praefect nodes are enough for redundancy.
|
||||
- PostgreSQL and PgBouncer: A quorum is not strictly necessary. Two PostgreSQL nodes and two PgBouncer nodes are enough for redundancy.
|
||||
- Running select components in reputable Cloud PaaS solutions: Select components of the GitLab setup can instead be run on Cloud Provider PaaS solutions. By doing this, additional dependent components can also be removed:
|
||||
- PostgreSQL: Can be run on reputable Cloud PaaS solutions such as Google Cloud SQL or Amazon RDS. In this setup, the PgBouncer and Consul nodes are no longer required:
|
||||
- Consul may still be desired if [Prometheus](../monitoring/prometheus/index.md) auto discovery is a requirement, otherwise you would need to [manually add scrape configurations](../monitoring/prometheus/index.md#adding-custom-scrape-configurations) for all nodes.
|
||||
|
|
|
|||
|
|
@ -1468,10 +1468,12 @@ the file of the same name on this server. If this is the first Omnibus node you
|
|||
### Configure Gitaly
|
||||
|
||||
The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
|
||||
requirements that are dependent on data, specifically the number of projects
|
||||
and those projects' sizes. It's recommended that a Gitaly Cluster stores
|
||||
no more than 5 TB of data on each node. Depending on your
|
||||
repository storage requirements, you may require additional Gitaly Clusters.
|
||||
requirements that are dependent on data and load.
|
||||
|
||||
NOTE:
|
||||
The Reference Architecture specs have been designed with good headroom in mind
|
||||
but for Gitaly, increased specs or additional
|
||||
Gitaly Cluster arrays may be required for notably large data sets or load.
|
||||
|
||||
Due to Gitaly having notable input and output requirements, we strongly
|
||||
recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
|
||||
|
|
|
|||
|
|
@ -1397,10 +1397,12 @@ the file of the same name on this server. If this is the first Omnibus node you
|
|||
### Configure Gitaly
|
||||
|
||||
The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
|
||||
requirements that are dependent on data, specifically the number of projects
|
||||
and those projects' sizes. It's recommended that a Gitaly Cluster stores
|
||||
no more than 5 TB of data on each node. Depending on your
|
||||
repository storage requirements, you may require additional Gitaly Clusters.
|
||||
requirements that are dependent on data and load.
|
||||
|
||||
NOTE:
|
||||
The Reference Architecture specs have been designed with good headroom in mind
|
||||
but for Gitaly, increased specs or additional
|
||||
Gitaly Cluster arrays may be required for notably large data sets or load.
|
||||
|
||||
Due to Gitaly having notable input and output requirements, we strongly
|
||||
recommend that all Gitaly nodes use solid-state drives (SSDs). These SSDs
|
||||
|
|
|
|||
|
|
@ -11043,7 +11043,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
|
|||
|
||||
##### `GeoNode.jobArtifactRegistries`
|
||||
|
||||
Find Job Artifact registries on this Geo node.
|
||||
Find Job Artifact registries on this Geo node Available only when feature flag `geo_job_artifact_replication` is enabled. This flag is disabled by default, because the feature is experimental and is subject to change without notice.
|
||||
|
||||
Returns [`JobArtifactRegistryConnection`](#jobartifactregistryconnection).
|
||||
|
||||
|
|
|
|||
|
|
@ -150,6 +150,10 @@ message with a status code of `401`:
|
|||
}
|
||||
```
|
||||
|
||||
NOTE:
|
||||
Deploy tokens can't be used with the GitLab public API. For details, see
|
||||
[Deploy Tokens](../user/project/deploy_tokens/index.md).
|
||||
|
||||
### OAuth2 tokens
|
||||
|
||||
You can use an [OAuth2 token](oauth2.md) to authenticate with the API by passing
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ tier. Users can continue to access the features in a paid tier without sharing u
|
|||
|
||||
#### Features available in 14.1 and later
|
||||
|
||||
1. [Email from GitLab](../../tools/email.md).
|
||||
1. [Email from GitLab](../../user/admin_area/email_from_gitlab.md).
|
||||
|
||||
#### Features available in 14.4 and later
|
||||
|
||||
|
|
|
|||
|
|
@ -13,28 +13,27 @@ related to changing a model's confidential/public flag.
|
|||
|
||||
## Add support to the GraphQL mutations
|
||||
|
||||
This implementation is very similar to the controller implementation. You create a `spam_params`
|
||||
instance based on the request, and pass it to the relevant Service class constructor.
|
||||
The main steps are:
|
||||
|
||||
The three main differences from the controller implementation are:
|
||||
1. Use `include Mutations::SpamProtection` in your mutation.
|
||||
1. Create a `spam_params` instance based on the request. Obtain the request from the context
|
||||
via `context[:request]` when creating the `SpamParams` instance.
|
||||
1. Pass `spam_params` to the relevant Service class constructor.
|
||||
1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`
|
||||
and pass it the model instance. This call:
|
||||
1. Performs the necessary spam checks on the model.
|
||||
1. If spam is detected:
|
||||
- Raises a `GraphQL::ExecutionError` exception.
|
||||
- Includes the relevant information added as error fields to the response via the `extensions:` parameter.
|
||||
For more details on these fields, refer to the section in the GraphQL API documentation on
|
||||
[Resolve mutations detected as spam](../../api/graphql/index.md#resolve-mutations-detected-as-spam).
|
||||
|
||||
1. Use `include Mutations::SpamProtection` instead of `...JsonFormatActionsSupport`.
|
||||
1. Obtain the request from the context via `context[:request]` when creating the `SpamParams`
|
||||
instance.
|
||||
1. After you create or updated the `Spammable` model instance, call `#check_spam_action_response!`
|
||||
and pass it the model instance. This call will:
|
||||
1. Perform the necessary spam checks on the model.
|
||||
1. If spam is detected:
|
||||
- Raise a `GraphQL::ExecutionError` exception.
|
||||
- Include the relevant information added as error fields to the response via the `extensions:` parameter.
|
||||
For more details on these fields, refer to the section on
|
||||
[Spam and CAPTCHA support in the GraphQL API](../../api/graphql/index.md#resolve-mutations-detected-as-spam).
|
||||
|
||||
NOTE:
|
||||
If you use the standard ApolloLink or Axios interceptor CAPTCHA support described
|
||||
above, the field details are unimportant. They become important if you
|
||||
attempt to use the GraphQL API directly to process a failed check for potential spam, and
|
||||
resubmit the request with a solved CAPTCHA response.
|
||||
NOTE:
|
||||
If you use the standard ApolloLink or Axios interceptor CAPTCHA support described
|
||||
above, you can ignore the field details, because they are handled
|
||||
automatically. They become relevant if you attempt to use the GraphQL API directly to
|
||||
process a failed check for potential spam, and resubmit the request with a solved
|
||||
CAPTCHA response.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -57,10 +56,13 @@ module Mutations
|
|||
widget = service_response.payload[:widget]
|
||||
check_spam_action_response!(widget)
|
||||
|
||||
# If possible spam wasdetected, an exception would have been thrown by
|
||||
# If possible spam was detected, an exception would have been thrown by
|
||||
# `#check_spam_action_response!`, so the normal resolve return logic can follow below.
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
Refer to the [Exploratory Testing](exploratory_testing.md) section for instructions on how to test
|
||||
CAPTCHA behavior in the GraphQL API.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ To add this support, you must implement the following areas as applicable:
|
|||
1. [Model and Services](model_and_services.md): The basic prerequisite
|
||||
changes to the backend code which are required to add spam or CAPTCHA API and UI support
|
||||
for a feature which does not yet have support.
|
||||
1. REST API (Supported, documentation coming soon): The changes needed to add
|
||||
1. [REST API](rest_api.md): The changes needed to add
|
||||
spam or CAPTCHA support to Grape REST API endpoints. Refer to the related
|
||||
[REST API documentation](../../api/index.md#resolve-requests-detected-as-spam).
|
||||
1. [GraphQL API](graphql_api.md): The changes needed to add spam or CAPTCHA support to GraphQL
|
||||
|
|
|
|||
90
doc/development/spam_protection_and_captcha/rest_api.md
Normal file
90
doc/development/spam_protection_and_captcha/rest_api.md
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
---
|
||||
stage: Manage
|
||||
group: Authentication and Authorization
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# REST API spam protection and CAPTCHA support
|
||||
|
||||
If the model can be modified via the REST API, you must also add support to all of the
|
||||
relevant API endpoints which may modify spammable or spam-related attributes. This
|
||||
definitely includes the `POST` and `PUT` mutations, but may also include others, such as those
|
||||
related to changing a model's confidential/public flag.
|
||||
|
||||
## Add support to the REST endpoints
|
||||
|
||||
The main steps are:
|
||||
|
||||
1. Add `helpers SpammableActions::CaptchaCheck::RestApiActionsSupport` in your `resource`.
|
||||
1. Create a `spam_params` instance based on the request.
|
||||
1. Pass `spam_params` to the relevant Service class constructor.
|
||||
1. After you create or update the `Spammable` model instance, call `#check_spam_action_response!`,
|
||||
save the created or updated instance in a variable.
|
||||
1. Identify the error handling logic for the `failure` case of the request,
|
||||
when create or update was not successful. These indicate possible spam detection,
|
||||
which adds an error to the `Spammable` instance.
|
||||
The error is usually similar to `render_api_error!` or `render_validation_error!`.
|
||||
1. Wrap the existing error handling logic in a
|
||||
`with_captcha_check_rest_api(spammable: my_spammable_instance)` call, passing the `Spammable`
|
||||
model instance you saved in a variable as the `spammable:` named argument. This call will:
|
||||
1. Perform the necessary spam checks on the model.
|
||||
1. If spam is detected:
|
||||
- Raise a Grape `#error!` exception with a descriptive spam-specific error message.
|
||||
- Include the relevant information added as error fields to the response.
|
||||
For more details on these fields, refer to the section in the REST API documentation on
|
||||
[Resolve requests detected as spam](../../api/index.md#resolve-requests-detected-as-spam).
|
||||
|
||||
NOTE:
|
||||
If you use the standard ApolloLink or Axios interceptor CAPTCHA support described
|
||||
above, you can ignore the field details, because they are handled
|
||||
automatically. They become relevant if you attempt to use the GraphQL API directly to
|
||||
process a failed check for potential spam, and resubmit the request with a solved
|
||||
CAPTCHA response.
|
||||
|
||||
Here is an example for the `post` and `put` actions on the `snippets` resource:
|
||||
|
||||
```ruby
|
||||
module API
|
||||
class Snippets < ::API::Base
|
||||
#...
|
||||
resource :snippets do
|
||||
# This helper provides `#with_captcha_check_rest_api`
|
||||
helpers SpammableActions::CaptchaCheck::RestApiActionsSupport
|
||||
|
||||
post do
|
||||
#...
|
||||
spam_params = ::Spam::SpamParams.new_from_request(request: request)
|
||||
service_response = ::Snippets::CreateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute
|
||||
snippet = service_response.payload[:snippet]
|
||||
|
||||
if service_response.success?
|
||||
present snippet, with: Entities::PersonalSnippet, current_user: current_user
|
||||
else
|
||||
# Wrap the normal error response in a `with_captcha_check_rest_api(spammable: snippet)` block
|
||||
with_captcha_check_rest_api(spammable: snippet) do
|
||||
# If possible spam was detected, an exception would have been thrown by
|
||||
# `#with_captcha_check_rest_api` for Grape to handle via `error!`
|
||||
render_api_error!({ error: service_response.message }, service_response.http_status)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
put ':id' do
|
||||
#...
|
||||
spam_params = ::Spam::SpamParams.new_from_request(request: request)
|
||||
service_response = ::Snippets::UpdateService.new(project: nil, current_user: current_user, params: attrs, spam_params: spam_params).execute(snippet)
|
||||
|
||||
snippet = service_response.payload[:snippet]
|
||||
|
||||
if service_response.success?
|
||||
present snippet, with: Entities::PersonalSnippet, current_user: current_user
|
||||
else
|
||||
# Wrap the normal error response in a `with_captcha_check_rest_api(spammable: snippet)` block
|
||||
with_captcha_check_rest_api(spammable: snippet) do
|
||||
# If possible spam was detected, an exception would have been thrown by
|
||||
# `#with_captcha_check_rest_api` for Grape to handle via `error!`
|
||||
render_api_error!({ error: service_response.message }, service_response.http_status)
|
||||
end
|
||||
end
|
||||
end
|
||||
```
|
||||
|
|
@ -37,7 +37,7 @@ additional fields being added to the models. Instead, communication is handled:
|
|||
The spam and CAPTCHA-related logic is also cleanly abstracted into reusable modules and helper methods
|
||||
which can wrap existing logic, and only alter the existing flow if potential spam
|
||||
is detected or a CAPTCHA display is needed. This approach allows the spam and CAPTCHA
|
||||
support to be easily added to new areas of the application with minimal changes to
|
||||
support to be added to new areas of the application with minimal changes to
|
||||
existing logic. In the case of the frontend, potentially **zero** changes are needed!
|
||||
|
||||
On the frontend, this is handled abstractly and transparently using `ApolloLink` for Apollo, and an
|
||||
|
|
@ -75,7 +75,7 @@ sequenceDiagram
|
|||
The backend is also cleanly abstracted via mixin modules and helper methods. The three main
|
||||
changes required to the relevant backend controller actions (normally just `create`/`update`) are:
|
||||
|
||||
1. Create a `SpamParams` parameter object instance based on the request, using the simple static
|
||||
1. Create a `SpamParams` parameter object instance based on the request, using the static
|
||||
`#new_from_request` factory method. This method takes a request, and returns a `SpamParams` instance.
|
||||
1. Pass the created `SpamParams` instance as the `spam_params` named argument to the
|
||||
Service class constructor, which you should have already added. If the spam check indicates
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ the tiers are no longer mentioned in GitLab documentation:
|
|||
- [Code owners](../user/project/code_owners.md)
|
||||
- Description templates:
|
||||
- [Setting a default template for merge requests and issues](../user/project/description_templates.md#set-a-default-template-for-merge-requests-and-issues)
|
||||
- [Email from GitLab](../tools/email.md)
|
||||
- [Email from GitLab](../user/admin_area/email_from_gitlab.md)
|
||||
- Groups:
|
||||
- [Creating group memberships via CN](../user/group/index.md#create-group-links-via-cn)
|
||||
- [Group push rules](../user/group/index.md#group-push-rules)
|
||||
|
|
|
|||
|
|
@ -1,60 +1,11 @@
|
|||
---
|
||||
stage: none
|
||||
group: unassigned
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
type: howto, reference
|
||||
redirect_to: '../user/admin_area/email_from_gitlab.md'
|
||||
remove_date: '2022-06-18'
|
||||
---
|
||||
|
||||
# Email from GitLab **(PREMIUM SELF)**
|
||||
This document was moved to [another location](../user/admin_area/email_from_gitlab.md).
|
||||
|
||||
GitLab provides a tool to administrators for emailing all users, or users of
|
||||
a chosen group or project, right from the Admin Area. Users receive the email
|
||||
at their primary email address.
|
||||
|
||||
For information about email notifications originating from GitLab, read
|
||||
[GitLab notification emails](../user/profile/notifications.md).
|
||||
|
||||
## 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 downtime is expected
|
||||
for a particular reason.
|
||||
|
||||
## Sending emails to users from within GitLab
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
1. On the left sidebar, select **Overview > Users**.
|
||||
1. Select **Send email to users**.
|
||||
|
||||
|
||||
|
||||
1. Compose an email and choose where to send it (all users or users of a
|
||||
chosen group or project). The email body only supports plain text messages.
|
||||
HTML, Markdown, and other rich text formats are not supported, and is
|
||||
sent as plain text to users.
|
||||
|
||||
|
||||
|
||||
NOTE:
|
||||
[Starting with GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/31509), email notifications can be sent only once every 10 minutes. This helps minimize performance issues.
|
||||
|
||||
## Unsubscribing from emails
|
||||
|
||||
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.
|
||||
|
||||
On unsubscribe, users receive an email notification that unsubscribe happened.
|
||||
The endpoint that provides the unsubscribe option is rate-limited.
|
||||
|
||||
<!-- ## 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. -->
|
||||
<!-- This redirect file can be deleted after <2022-06-18>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
60
doc/user/admin_area/email_from_gitlab.md
Normal file
60
doc/user/admin_area/email_from_gitlab.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
stage: none
|
||||
group: unassigned
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
type: howto, reference
|
||||
---
|
||||
|
||||
# Email from GitLab **(PREMIUM SELF)**
|
||||
|
||||
GitLab provides a tool to administrators for emailing all users, or users of
|
||||
a chosen group or project, right from the Admin Area. Users receive the email
|
||||
at their primary email address.
|
||||
|
||||
For information about email notifications originating from GitLab, read
|
||||
[GitLab notification emails](../profile/notifications.md).
|
||||
|
||||
## 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 downtime is expected
|
||||
for a particular reason.
|
||||
|
||||
## Sending emails to users from GitLab
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
1. On the left sidebar, select **Overview > Users**.
|
||||
1. Select **Send email to users**.
|
||||
|
||||
|
||||
|
||||
1. Compose an email and choose where to send it (all users or users of a
|
||||
chosen group or project). The email body only supports plain text messages.
|
||||
HTML, Markdown, and other rich text formats are not supported, and is
|
||||
sent as plain text to users.
|
||||
|
||||
|
||||
|
||||
NOTE:
|
||||
[Starting with GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/31509), email notifications can be sent only once every 10 minutes. This helps minimize performance issues.
|
||||
|
||||
## Unsubscribing from emails
|
||||
|
||||
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.
|
||||
|
||||
On unsubscribe, users receive an email notification that unsubscribe happened.
|
||||
The endpoint that provides the unsubscribe option is rate-limited.
|
||||
|
||||
<!-- ## 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. -->
|
||||
|
Before Width: | Height: | Size: 9.4 KiB After Width: | Height: | Size: 9.4 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
|
@ -132,7 +132,8 @@ There are other additional predefined CI/CD variables you can also use:
|
|||
- `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX`: the image prefix for pulling images through the
|
||||
dependency proxy from the direct group or subgroup that the project belongs to.
|
||||
|
||||
`CI_DEPENDENCY_PROXY_SERVER` and `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`
|
||||
`CI_DEPENDENCY_PROXY_SERVER`, `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`, and
|
||||
`CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX`
|
||||
include the server port. If you explicitly include the Dependency Proxy
|
||||
path, the port must be included, unless you have logged into the Dependency
|
||||
Proxy manually without including the port:
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Stay informed about what's happening in GitLab with email notifications.
|
|||
You can receive updates about activity in issues, merge requests, epics, and designs.
|
||||
|
||||
For the tool that GitLab administrators can use to send messages to users, read
|
||||
[Email from GitLab](../../tools/email.md).
|
||||
[Email from GitLab](../admin_area/email_from_gitlab.md).
|
||||
|
||||
## Who receives notifications
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ If you no longer wish to receive any email notifications:
|
|||
**Disabled**.
|
||||
|
||||
On self-managed installations, even after doing this, your instance administrator
|
||||
[can still email you](../../tools/email.md).
|
||||
[can still email you](../admin_area/email_from_gitlab.md).
|
||||
To unsubscribe, select the unsubscribe link in one of these emails.
|
||||
|
||||
## Email headers you can use to filter email
|
||||
|
|
|
|||
|
|
@ -16,7 +16,9 @@ container registry images of a project without having a user and a password.
|
|||
|
||||
Deploy tokens can be managed only by users with the Maintainer role.
|
||||
|
||||
Deploy tokens cannot be used with the GitLab API.
|
||||
Deploy tokens can't be used with the GitLab public API. However, you can use deploy tokens with some
|
||||
endpoints, such as those from the Package Registry. For details, see
|
||||
[Authenticate with the registry](../../packages/package_registry/index.md#authenticate-with-the-registry).
|
||||
|
||||
Deploy tokens are tied to the project and stay enabled even when the user who created the token is removed from the project.
|
||||
|
||||
|
|
|
|||
|
|
@ -383,3 +383,17 @@ s = Gitlab::ImportExport::Saver.new(exportable: p, shared:p.import_export_shared
|
|||
s.send(:compress_and_save)
|
||||
s.send(:save_upload)
|
||||
```
|
||||
|
||||
### Import using the REST API fails when using a group access token
|
||||
|
||||
[Group access tokens](../../group/settings/group_access_tokens.md)
|
||||
don't work for project or group import operations. When a group access token initiates an import,
|
||||
the import fails with this message:
|
||||
|
||||
```plaintext
|
||||
Error adding importer user to Project members.
|
||||
Validation failed: User project bots cannot be added to other groups / projects
|
||||
```
|
||||
|
||||
To use [Import REST APIs](../../../api/project_import_export.md),
|
||||
pass regular user account credentials such as [personal access tokens](../../profile/personal_access_tokens.md).
|
||||
|
|
|
|||
|
|
@ -5,20 +5,36 @@ module Gitlab
|
|||
module Status
|
||||
module Build
|
||||
class Manual < Status::Extended
|
||||
def self.matches?(build, user)
|
||||
build.playable?
|
||||
end
|
||||
|
||||
def illustration
|
||||
{
|
||||
image: 'illustrations/manual_action.svg',
|
||||
size: 'svg-394',
|
||||
title: _('This job requires a manual action'),
|
||||
content: _('This job requires manual intervention to start. Before starting this job, you can add variables below for last-minute configuration changes.')
|
||||
content: illustration_content
|
||||
}
|
||||
end
|
||||
|
||||
def self.matches?(build, user)
|
||||
build.playable?
|
||||
private
|
||||
|
||||
def illustration_content
|
||||
if can?(user, :update_build, subject)
|
||||
_('This job requires manual intervention to start. Before starting this job, you can add variables below for last-minute configuration changes.')
|
||||
else
|
||||
generic_permission_failure_message
|
||||
end
|
||||
end
|
||||
|
||||
def generic_permission_failure_message
|
||||
_("This job does not run automatically and must be started manually, but you do not have access to it.")
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
Gitlab::Ci::Status::Build::Manual.prepend_mod_with('Gitlab::Ci::Status::Build::Manual')
|
||||
|
|
|
|||
|
|
@ -1811,6 +1811,9 @@ msgstr ""
|
|||
msgid "About this feature"
|
||||
msgstr ""
|
||||
|
||||
msgid "About your company"
|
||||
msgstr ""
|
||||
|
||||
msgid "Abuse Reports"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -16782,6 +16785,9 @@ msgstr ""
|
|||
msgid "GitLab Team Member"
|
||||
msgstr ""
|
||||
|
||||
msgid "GitLab Ultimate trial"
|
||||
msgstr ""
|
||||
|
||||
msgid "GitLab User"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -37976,6 +37982,9 @@ msgstr ""
|
|||
msgid "This deployment is not waiting for approvals."
|
||||
msgstr ""
|
||||
|
||||
msgid "This deployment job does not run automatically and must be started manually, but you do not have access to this job's protected environment. The job can only be started by a project member allowed to deploy to the environment."
|
||||
msgstr ""
|
||||
|
||||
msgid "This device has already been registered with us."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -38138,6 +38147,9 @@ msgstr ""
|
|||
msgid "This job does not have a trace."
|
||||
msgstr ""
|
||||
|
||||
msgid "This job does not run automatically and must be started manually, but you do not have access to it."
|
||||
msgstr ""
|
||||
|
||||
msgid "This job has been canceled"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -39432,6 +39444,9 @@ msgstr ""
|
|||
msgid "Try again?"
|
||||
msgstr ""
|
||||
|
||||
msgid "Try all GitLab features for free for 30 days. No credit card required."
|
||||
msgstr ""
|
||||
|
||||
msgid "Try all GitLab has to offer for 30 days."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -41874,6 +41889,9 @@ msgstr ""
|
|||
msgid "Webhooks|Wiki page events"
|
||||
msgstr ""
|
||||
|
||||
msgid "Website"
|
||||
msgstr ""
|
||||
|
||||
msgid "Website:"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ describe('Markdown field header component', () => {
|
|||
it('hides toolbar in preview mode', () => {
|
||||
createWrapper({ previewMarkdown: true });
|
||||
|
||||
expect(findToolbar().classes().includes('gl-display-none')).toBe(true);
|
||||
expect(findToolbar().classes().includes('gl-display-none!')).toBe(true);
|
||||
});
|
||||
|
||||
it('emits toggle markdown event when clicking preview tab', async () => {
|
||||
|
|
|
|||
|
|
@ -3,15 +3,27 @@
|
|||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Gitlab::Ci::Status::Build::Manual do
|
||||
let(:user) { create(:user) }
|
||||
let_it_be(:user) { create(:user) }
|
||||
let_it_be(:job) { create(:ci_build, :manual) }
|
||||
|
||||
subject do
|
||||
build = create(:ci_build, :manual)
|
||||
described_class.new(Gitlab::Ci::Status::Core.new(build, user))
|
||||
described_class.new(Gitlab::Ci::Status::Core.new(job, user))
|
||||
end
|
||||
|
||||
describe '#illustration' do
|
||||
it { expect(subject.illustration).to include(:image, :size, :title, :content) }
|
||||
|
||||
context 'when the user can trigger the job' do
|
||||
before do
|
||||
job.project.add_maintainer(user)
|
||||
end
|
||||
|
||||
it { expect(subject.illustration[:content]).to match /This job requires manual intervention to start/ }
|
||||
end
|
||||
|
||||
context 'when the user can not trigger the job' do
|
||||
it { expect(subject.illustration[:content]).to match /This job does not run automatically and must be started manually/ }
|
||||
end
|
||||
end
|
||||
|
||||
describe '.matches?' do
|
||||
|
|
|
|||
Loading…
Reference in a new issue