realaravinth/debian-mirror-gitlab
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
debian-mirror-gitlab/doc/user/group/manage.md
Pirate Praveen 54117d12b7 New upstream version 15.5.4+ds1
2022-11-25 23:54:43 +05:30

38 KiB
Raw Blame History

stage group info
Manage Workspace To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

Manage groups

Use groups to manage one or more related projects at the same time.

View groups

To view groups, on the top bar, select Main menu > Groups > View all groups.

The Groups page shows a list of groups, sorted by last updated date.

  • To explore all public groups, select Explore groups.
  • To view groups where you have a direct or indirect membership, select Your groups. This tab shows groups that you are a member of:
    • Through membership of a subgroup's parent group.
    • Through direct or inherited membership of a project in the group or subgroup.

Create a group

To create a group:

  1. On the top bar, either:
    • Select Main menu > Groups > View all groups, and on the right, select New group.
    • To the left of the search box, select the plus sign and then New group.
  2. Select Create group.
  3. Enter a name for the group in Group name. For a list of words that cannot be used as group names, see reserved names.
  4. Enter a path for the group in Group URL, which is used for the namespace.
  5. Choose the visibility level.
  6. Personalize your GitLab experience by answering the following questions:
    • What is your role?
    • Who will be using this group?
    • What will you use this group for?
  7. Invite GitLab members or other users to join the group.

For details about groups, watch GitLab Namespaces (users, groups and subgroups).

Remove a group

To remove a group and its contents:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Advanced section.
  4. In the Remove group section, select Remove group.
  5. Type the group name.
  6. Select Confirm.

A group can also be removed from the groups dashboard:

  1. On the top bar, select Main menu > Groups > View all groups.
  2. Select Your Groups.
  3. Select ({ellipsis_v}) for the group you want to delete.
  4. Select Delete.
  5. In the Remove group section, select Remove group.
  6. Type the group name.
  7. Select Confirm.

This action removes the group. It also adds a background job to delete all projects in the group.

Specifically:

  • In GitLab 12.8 and later, on GitLab Premium or higher tiers, this action adds a background job to mark a group for deletion. By default, the job schedules the deletion 7 days in the future. You can modify this waiting period through the instance settings.
  • In GitLab 13.6 and later, if the user who sets up the deletion is removed from the group before the deletion happens, the job is cancelled, and the group is no longer scheduled for deletion.

Remove a group immediately (PREMIUM)

Introduced in GitLab 14.2.

If you don't want to wait, you can remove a group immediately.

Prerequisites:

To immediately remove a group marked for deletion:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand Advanced.
  4. In the "Permanently remove group" section, select Remove group.
  5. Confirm the action when asked to.

Your group, its subgroups, projects, and all related resources, including issues and merge requests, are deleted.

Restore a group (PREMIUM)

Introduced in GitLab 12.8.

To restore a group that is marked for deletion:

  1. On the top bar, select Main menu > Groups and find your group.
  2. Select Settings > General.
  3. Expand the Path, transfer, remove section.
  4. In the Restore group section, select Restore group.

Request access to a group

As a user, you can request to be a member of a group, if an administrator allows it.

  1. On the top bar, select Main menu > Groups and find your group.
  2. Under the group name, select Request Access.

As many as ten of the most-recently-active group owners receive an email with your request. Any group owner can approve or decline the request.

If you change your mind before your request is approved, select Withdraw Access Request.

Filter and sort members in a group

To find members in a group, you can sort, filter, or search.

Filter a group

Filter a group to find members. By default, all members in the group and subgroups are displayed.

In lists of group members, entries can display the following badges:

  1. On the top bar, select Main menu > Groups and find your group.
  2. Above the list of members, in the Filter members box, enter filter criteria.
    • To view members in the group only, select Membership = Direct.
    • To view members of the group and its subgroups, select Membership = Inherited.
    • To view members with two-factor authentication enabled or disabled, select 2FA = Enabled or Disabled.
    • In GitLab 14.0 and later, to view GitLab users created by SAML SSO or SCIM provisioning select Enterprise = true.

Search a group

You can search for members by name, username, or email.

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Group information > Members.
  3. Above the list of members, in the Filter members box, enter search criteria.
  4. To the right of the Filter members box, select the magnifying glass ({search}).

Sort members in a group

You can sort members by Account, Access granted, Max role, or Last sign-in.

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Group information > Members.
  3. Above the list of members, on the top right, from the Account list, select the criteria to filter by.
  4. To switch the sort between ascending and descending, to the right of the Account list, select the arrow ({sort-lowest} or {sort-highest}).

Add users to a group

You can give a user access to all projects in a group.

Prerequisite:

  • You must have the Owner role.
  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Group information > Members.
  3. Select Invite members.
  4. Fill in the fields.
    • The role applies to all projects in the group. Learn more about permissions.
    • On the Access expiration date, the user can no longer access projects in the group.
  5. Select Invite.

Members that are not automatically added are displayed on the Invited tab. Users can be on this tab because they:

Remove a member from the group

Prerequisites:

  • You must have the Owner role.
  • The member must have direct membership in the group. If membership is inherited from a parent group, then the member can be removed from the parent group only.

To remove a member from a group:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Group information > Members.
  3. Next to the member you want to remove, select Remove member.
  4. Optional. On the Remove member confirmation box:
    • To remove direct user membership from subgroups and projects, select the Also remove direct user membership from subgroups and projects checkbox.
    • To unassign the user from linked issues and merge requests, select the Also unassign this user from linked issues and merge requests checkbox.
  5. Select Remove member.

Add projects to a group

There are two different ways to add a new project to a group:

  • Select a group, and then select New project. You can then continue creating your project.

  • While you are creating a project, select a group from the dropdown list.

    Select group

Specify who can add projects to a group

  • Introduced in GitLab 10.5.
  • Moved from GitLab Premium to GitLab Free in 11.10.

By default, users with at least the Developer role can create projects under a group.

To change this setting for a specific group:

  1. On the top bar, select Main menu > Groups > View all groups.
  2. Select Your Groups.
  3. Find the group and select it.
  4. From the left menu, select Settings > General.
  5. Expand the Permissions and group features section.
  6. Select the desired option in the Roles allowed to create projects dropdown list.
  7. Select Save changes.

To change this setting globally, see Default project creation protection.

Change the owner of a group

You can change the owner of a group. Each group must always have at least one member with the Owner role.

  • As an administrator:
    1. On the top bar, select Main menu > Groups and find your group.
    2. On the left sidebar, select Group information > Members.
    3. Give a different member the Owner role.
    4. Refresh the page. You can now remove the Owner role from the original owner.
  • As the current group's owner:
    1. On the top bar, select Main menu > Groups and find your group.
    2. On the left sidebar, select Group information > Members.
    3. Give a different member the Owner role.
    4. Have the new owner sign in and remove the Owner role from you.

Change a group's path

Changing a group's path (group URL) can have unintended side effects. Read how redirects behave before you proceed.

If you are changing the path so it can be claimed by another group or user, you must rename the group too. Both names and paths must be unique.

To retain ownership of the original namespace and protect the URL redirects, create a new group and transfer projects to it instead.

To change your group path (group URL):

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General page.
  3. Expand the Advanced section.
  4. Under Change group URL, enter a new name.
  5. Select Change group URL.

WARNING: It is not possible to rename a namespace if it contains a project with Container Registry tags, because the project cannot be moved.

Change the default branch protection of a group

By default, every group inherits the branch protection set at the global level.

To change this setting for a specific group, see group level default branch protection.

To change this setting globally, see initial default branch protection.

NOTE: In GitLab Premium or higher, GitLab administrators can choose to disable group owners from updating the default branch protection.

Use a custom name for the initial branch

Introduced in GitLab 13.6.

When you create a new project in GitLab, a default branch is created with the first push. The group owner can customize the initial branch for the group's projects to meet your group's needs.

Share a group with another group

Similar to how you share a project with a group, you can share a group with another group. To invite a group, you must be a member of it. Members get direct access to the shared group. This includes members who inherited group membership from a parent group.

To share a given group, for example, Frontend with another group, for example, Engineering:

  1. Go to the Frontend group.
  2. On the left sidebar, select Group information > Members.
  3. Select Invite a group.
  4. In the Select a group to invite list, select Engineering.
  5. Select a role as maximum access level.
  6. Select Invite.

After sharing the Frontend group with the Engineering group:

  • The Groups tab lists the Engineering group.
  • The Groups tab lists a group regardless of whether it is a public or private group.
  • All members of the Engineering group have access to the Frontend group. The same access levels of the members apply up to the maximum access level selected when sharing the group.

Transfer a group

You can transfer groups in the following ways:

  • Transfer a subgroup to a new parent group.
  • Convert a top-level group into a subgroup by transferring it to the desired group.
  • Convert a subgroup into a top-level group by transferring it out of its current group.

When transferring groups, note:

  • Changing a group's parent can have unintended side effects. See what happens when a repository path changes.
  • You can only transfer groups to groups you manage.
  • You must update your local repositories to point to the new location.
  • If the immediate parent group's visibility is lower than the group's current visibility, visibility levels for subgroups and projects change to match the new parent group's visibility.
  • Only explicit group membership is transferred, not inherited membership. If the group's owners have only inherited membership, this leaves the group without an owner. In this case, the user transferring the group becomes the group's owner.
  • Transfers fail if packages exist in any of the projects in the group, or in any of its subgroups.

To transfer a group:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Advanced section.
  4. In the Remove group section, select Transfer group.
  5. Select the group name in the drop down menu.
  6. Select Transfer group.

Enable delayed project deletion (PREMIUM)

Delayed project deletion is locked and disabled unless the instance-level settings for deletion protection are enabled for either groups only or groups and projects. When enabled on groups, projects in the group are deleted after a period of delay. During this period, projects are in a read-only state and can be restored. The default period is seven days but is configurable at the instance level.

On self-managed GitLab, projects are deleted immediately by default. In GitLab 14.2 and later, an administrator can change the default setting for projects in newly-created groups.

On GitLab.com, see the GitLab.com settings page for the default setting.

To enable delayed deletion of projects in a group:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Permissions and group features section.
  4. Scroll to:
    • (GitLab 15.1 and later) Deletion protection and select Keep deleted projects.
    • (GitLab 15.0 and earlier) Enable delayed project deletion and tick the checkbox.
  5. Optional. To prevent subgroups from changing this setting, select:
    • (GitLab 15.1 and later), Enforce deletion protection for all subgroups
    • (GitLab 15.0 and earlier), Enforce for all subgroups.
  6. Select Save changes.

NOTE: In GitLab 13.11 and above the group setting for delayed project deletion is inherited by subgroups. As discussed in Cascading settings inheritance can be overridden, unless enforced by an ancestor.

Compliance frameworks (PREMIUM)

You can create a compliance framework that is a label to identify that your project has certain compliance requirements or needs additional oversight. The label can optionally enforce compliance pipeline configuration to the projects on which it is applied.

Group owners can create, edit, and delete compliance frameworks:

  1. On the top bar, select Main menu > Groups > View all groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Compliance frameworks section.
  4. Create, edit, or delete compliance frameworks.

Configure a compliance pipeline (ULTIMATE)

Group owners can configure a compliance pipeline in a project separate to other projects. By default, the compliance pipeline configuration (.gitlab-ci.yml file) is run instead of the pipeline configuration of labeled projects.

However, the compliance pipeline configuration can reference the .gitlab-ci.yml file of the labeled projects so that:

  • The compliance pipeline can also run jobs of labeled project pipelines. This allows for centralized control of pipeline configuration.
  • Jobs and variables defined in the compliance pipeline can't be changed by variables in the labeled project's .gitlab-ci.yml file.

See example configuration for help configuring a compliance pipeline that runs jobs from labeled project pipeline configuration.

To configure a compliance pipeline:

  1. On the top bar, select Main menu > Groups > View all groups and find your group.

  2. On the left sidebar, select Settings > General.

  3. Expand the Compliance frameworks section.

  4. In Compliance pipeline configuration (optional), add the path to the compliance framework configuration. Use the path/file.y[a]ml@group-name/project-name format. For example:

    • .compliance-ci.yml@gitlab-org/gitlab.
    • .compliance-ci.yaml@gitlab-org/gitlab.

This configuration is inherited by projects where the compliance framework label is applied. In projects with the applied compliance framework label, the compliance pipeline configuration is run instead of the labeled project's own pipeline configuration.

The user running the pipeline in the labeled project must at least have the Reporter role on the compliance project.

When used to enforce scan execution, this feature has some overlap with scan execution policies. We have not unified the user experience for these two features. For details on the similarities and differences between these features, see Enforce scan execution.

Example configuration

The following example .compliance-gitlab-ci.yml includes the include keyword to ensure labeled project pipeline configuration is also executed.

# Allows compliance team to control the ordering and interweaving of stages/jobs.
# Stages without jobs defined will remain hidden.
stages:
  - pre-compliance
  - build
  - test
  - pre-deploy-compliance
  - deploy
  - post-compliance

variables:  # Can be overridden by setting a job-specific variable in project's local .gitlab-ci.yml
  FOO: sast

sast:  # None of these attributes can be overridden by a project's local .gitlab-ci.yml
  variables:
    FOO: sast
  image: ruby:2.6
  stage: pre-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

sanity check:
  image: ruby:2.6
  stage: pre-deploy-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

audit trail:
  image: ruby:2.7
  stage: post-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  project: '$CI_PROJECT_PATH'
  file: '$CI_CONFIG_PATH'
  ref: '$CI_COMMIT_REF_NAME' # Must be defined or MR pipelines always use the use default branch
CF pipelines in Merge Requests originating in project forks

When an MR originates in a fork, the branch to be merged usually only exists in the fork. When creating such an MR against a project with CF pipelines, the above snippet will fail with a Project <project-name> reference <branch-name> does not exist! error message. This is because in the context of the target project, $CI_COMMIT_REF_NAME evaluates to a non-existing branch name.

To get the correct context, use $CI_MERGE_REQUEST_SOURCE_PROJECT_PATH instead of $CI_PROJECT_PATH. This variable is only availabe in merge request pipelines.

For example, for a configuration that supports both branch pipelines, as well as merge request pipelines originating in project forks, you need to combine both include directives with rules:if:

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  - project: '$CI_MERGE_REQUEST_SOURCE_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_REF_NAME'
    rules:
      - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_REF_NAME'
    rules:
      - if: $CI_PIPELINE_SOURCE != 'merge_request_event'

Ensure compliance jobs are always run

Compliance pipelines use GitLab CI/CD to give you an incredible amount of flexibility for defining any sort of compliance jobs you like. Depending on your goals, these jobs can be configured to be:

  • Modified by users.
  • Non-modifiable.

Generally, if a value in a compliance job:

  • Is set, it cannot be changed or overridden by project-level configurations.
  • Is not set, a project-level configuration may set.

Either might be wanted or not depending on your use case.

There are a few best practices for ensuring that these jobs are always run exactly as you define them and that downstream, project-level pipeline configurations cannot change them:

  • Add a rules:when:always block to each of your compliance jobs. This ensures they are non-modifiable and are always run.
  • Explicitly set any variables the job references. This:
    • Ensures that project-level pipeline configurations do not set them and alter their behavior.
    • Includes any jobs that drive the logic of your job.
  • Explicitly set the container image to run the job in. This ensures that your script steps execute in the correct environment.
  • Explicitly set any relevant GitLab pre-defined job keywords. This ensures that your job uses the settings you intend and that they are not overridden by project-level pipelines.

Avoid parent and child pipelines in GitLab 14.7 and earlier

NOTE: This advice does not apply to GitLab 14.8 and later because a fix added compatibility for combining compliance pipelines, and parent and child pipelines.

Compliance pipelines start on the run of every pipeline in a labeled project. This means that if a pipeline in the labeled project triggers a child pipeline, the compliance pipeline runs first. This can trigger the parent pipeline, instead of the child pipeline.

Therefore, in projects with compliance frameworks, we recommend replacing parent-child pipelines with the following:

  • Direct include statements that provide the parent pipeline with child pipeline configuration.
  • Child pipelines placed in another project that are run using the trigger API rather than the parent-child pipeline feature.

This alternative ensures the compliance pipeline does not re-start the parent pipeline.

Disable email notifications

Introduced in GitLab 12.2.

You can disable all email notifications related to the group, which includes its subgroups and projects.

To disable email notifications:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Permissions and group features section.
  4. Select Email notifications are disabled.
  5. Select Save changes.

Disable group mentions

Introduced in GitLab 12.6.

You can prevent users from being added to a conversation and getting notified when anyone mentions a group in which those users are members.

Groups with disabled mentions are visualized accordingly in the autocompletion dropdown list.

This is particularly helpful for groups with a large number of users.

To disable group mentions:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Permissions and group features section.
  4. Select Group mentions are disabled.
  5. Select Save changes.

Export members as CSV (PREMIUM)

You can export a list of members in a group or subgroup as a CSV.

  1. On the top bar, select Main menu > Groups and find your group or subgroup.
  2. On the left sidebar, select either Group information > Members or Subgroup information > Members.
  3. Select Export as CSV.
  4. After the CSV file has been generated, it is emailed as an attachment to the user that requested it.

User cap for groups

Introduced in GitLab 14.7.

FLAG: On self-managed GitLab, this feature is not available. On GitLab.com, this feature is available for some groups. This feature is not ready for production use.

When the number of billable members reaches the user cap, new users can't be added to the group without being approved by the group owner.

Groups with the user cap feature enabled have group sharing disabled for the group and its subgroups.

Specify a user cap for a group

Prerequisite:

  • You must be assigned the Owner role) for the group.

To specify a user cap:

  1. On the top bar, select Main menu > Groups and find your group. You can set a cap on the top-level group only.
  2. On the left sidebar, select Settings > General.
  3. Expand Permissions and group features.
  4. In the User cap box, enter the desired number of users.
  5. Select Save changes.

If you already have more users in the group than the user cap value, users are not removed. However, you can't add more without approval.

Increasing the user cap does not approve pending members.

Remove the user cap for a group

You can remove the user cap, so there is no limit on the number of members you can add to a group.

Prerequisite:

  • You must be assigned the Owner role) for the group.

To remove the user cap:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand Permissions and group features.
  4. In the User cap box, delete the value.
  5. Select Save changes.

Decreasing the user cap does not approve pending members.

Approve pending members for a group

When the number of billable users reaches the user cap, any new member is put in a pending state and must be approved.

Pending members do not count as billable. Members count as billable only after they have been approved and are no longer in a pending state.

Prerequisite:

  • You must be assigned the Owner role) for the group.

To approve members that are pending because they've exceeded the user cap:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > Usage Quotas.
  3. On the Seats tab, under the alert, select View pending approvals.
  4. For each member you want to approve, select Approve.

Group file templates (PREMIUM)

Use group file templates to share a set of templates for common file types with every project in a group. It is analogous to the instance template repository. The selected project should follow the same naming conventions as are documented on that page.

You can only choose projects in the group as the template source. This includes projects shared with the group, but it excludes projects in subgroups or parent groups of the group being configured.

You can configure this feature for both subgroups and immediate parent groups. A project in a subgroup has access to the templates for that subgroup, as well as any immediate parent groups.

To learn how to create templates for issues and merge requests, see Description templates.

Define project templates at a group level by setting a group as the template source. Learn more about group-level project templates.

Enable group file template (PREMIUM)

To enable group file templates:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Templates section.
  4. Choose a project to act as the template repository.
  5. Select Save changes.

Group merge request approval settings (PREMIUM)

Group approval settings manage project merge request approval settings at the top-level group level. These settings cascade to all projects that belong to the group.

To view the merge request approval settings for a group:

  1. On the top bar, select Main menu > Groups and find your group.
  2. On the left sidebar, select Settings > General.
  3. Expand the Merge request approvals section.
  4. Select the settings you want.
  5. Select Save changes.

Support for group-level settings for merge request approval rules is tracked in this epic.

Group activity analytics (PREMIUM)

Introduced in GitLab 12.10 as a Beta feature.

For a group, you can view how many merge requests, issues, and members were created in the last 90 days.

These Group Activity Analytics can be enabled with the group_activity_analytics feature flag.

Recent Group Activity

Changes to group wikis do not appear in group activity analytics.

View group activity

You can view the most recent actions taken in a group, either in your browser or in an RSS feed:

  1. On the top bar, select Main menu > Groups > View all groups and find your group.
  2. On the left sidebar, select Group information > Activity.

To view the activity feed in Atom format, select the RSS ({rss}) icon.

Troubleshooting

Validation errors on namespaces and groups

GitLab 14.4 and later performs the following checks when creating or updating namespaces or groups:

  • Namespaces must not have parents.
  • Group parents must be groups and not namespaces.

In the unlikely event that you see these errors in your GitLab installation, contact Support so that we can improve this validation.

Find groups using an SQL query

To find and store an array of groups based on an SQL query in the rails console:

# Finds groups and subgroups that end with '%oup'
Group.find_by_sql("SELECT * FROM namespaces WHERE name LIKE '%oup'")
=> [#<Group id:3 @test-group>, #<Group id:4 @template-group/template-subgroup>]

Transfer subgroup to another location using Rails console

If transferring a group doesn't work through the UI or API, you may want to attempt the transfer in a Rails console session:

WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

user = User.find_by_username('<username>')
group = Group.find_by_name("<group_name>")
## Set parent_group = nil to make the subgroup a top-level group
parent_group = Group.find_by(id: "<group_id>")
service = ::Groups::TransferService.new(group, user)
service.execute(parent_group)

Find groups pending deletion using Rails console

If you need to find all the groups that are pending deletion, you can use the following command in a Rails console session:

Group.all.each do |g|
 if g.marked_for_deletion?
    puts "Group ID: #{g.id}"
    puts "Group name: #{g.name}"
    puts "Group path: #{g.full_path}"
 end
end

Delete a group using Rails console

At times, a group deletion may get stuck. If needed, in a Rails console session, you can attempt to delete a group using the following command:

WARNING: Any command that changes data directly could be damaging if not run correctly, or under the right conditions. We highly recommend running them in a test environment with a backup of the instance ready to be restored, just in case.

GroupDestroyWorker.new.perform(group_id, user_id)