@@ -114,11 +114,9 @@ See the documentation on [File Locking](../../../user/project/file_lock.md).
## LFS objects in project archives
> - Support for including Git LFS blobs inside [project source downloads](../../../user/project/repository/index.md) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15079) in GitLab 13.5.
> - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/268409) in GitLab 13.6.
> - Enabled on GitLab.com.
> - Recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-lfs-objects-in-project-archives).
WARNING:
This feature might not be available to you. Check the **version history** note above for details.
...
...
@@ -134,31 +132,11 @@ oid sha256:3ea5dd307f195f449f0e08234183b82e92c3d5f4cff11c2a6bb014f9e0de12aa
size 177735
```
Starting with GitLab 13.5, these pointers are converted to the uploaded
LFS object if the `include_lfs_blobs_in_archive` feature flag is
enabled.
In GitLab version 13.5 and later, these pointers are converted to the uploaded
LFS object.
Technical details about how this works can be found in the [development documentation for LFS](../../../development/lfs.md#including-lfs-blobs-in-project-archives).
### Enable or disable LFS objects in project archives
_LFS objects in project archives_ is under development but ready for production use.
It is deployed behind a feature flag that is **enabled by default**.
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
can opt to disable it.
To enable it:
```ruby
Feature.enable(:include_lfs_blobs_in_archive)
```
To disable it:
```ruby
Feature.disable(:include_lfs_blobs_in_archive)
```
## Troubleshooting
### Encountered `n` file(s) that should have been pointers, but weren't
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
---
# Permissions
# Permissions and roles
Users have different abilities depending on the access level they have in a
Users have different abilities depending on the role they have in a
particular group or project. If a user is both in a project's group and the
project itself, the highest permission level is used.
project itself, the highest role is used.
On public and internal projects, the Guest role is not enforced. All users can:
...
...
@@ -39,11 +39,11 @@ usernames. A GitLab administrator can configure the GitLab instance to
NOTE:
In GitLab 11.0, the Master role was renamed to Maintainer.
The Owner permission is only available at the group or personal namespace level (and for instance administrators) and is inherited by its projects.
The Owner role is only available at the group or personal namespace level (and for instance administrators) and is inherited by its projects.
While Maintainer is the highest project-level role, some actions can only be performed by a personal namespace or group owner, or an instance administrator, who receives all permissions.
For more information, see [projects members documentation](project/members/index.md).
The following table depicts the various user permission levels in a project.
The following table lists project permissions available for each role:
@@ -22,14 +22,15 @@ There are two kinds of repository mirroring supported by GitLab:
When the mirror repository is updated, all new branches, tags, and commits are visible in the
project's activity feed.
Users with [Maintainer access](../../permissions.md) to the project can also force an
Users with the [Maintainer role](../../permissions.md) for the project can also force an
immediate update, unless:
- The mirror is already being updated.
- The [limit for pull mirroring interval seconds](../../../administration/instance_limits.md#pull-mirroring-interval) has not elapsed since its last update.
For security reasons, the URL to the original repository is only displayed to users with
Maintainer or Owner permissions to the mirrored project.
For security reasons, the URL to the original repository is only displayed to users with the
[Maintainer role](../../permissions.md) or the [Owner role](../../permissions.md) for the mirrored
