In our organisation we recently moving to git, I have created a group accidentally I would be appreciate if there is a way to delete this group.
In the most recent version (Mar. 2019):
At top bar, click on Groups.
Type part of the name of the desired group or click on Explore Groups. Click on the desired group.
Go to Settings > General
Expand Path, transfer, remove
At the bottom of page you find Remove group. Click on the button and type the name of the group to activate Confirm button. Then click on Confirm to delete the group.
On the recent version (per posting date 11.4.4) navigate to your group's
Settings > General > Advanced > Expand
There you will find the Remove group button.
The group deletion has changed with GitLab 14.8 (February 2022)
Delete groups at the parent group level
In this milestone, we’ve worked on one of the initial steps to reach feature parity between group owners (in any installation base) and administrator-only functionality that exists solely in the administrator panel for self-managed users.
Group owners can now delete a group and its subgroups from the parent group level. Until now, group owners had to go into each individual group to delete them, which was timely and inefficient. Group owners can now view all groups and delete them from a single place.
See Documentation and Issue.
Note: GitLab 15.4 (September 2022), but only the non-free version, comes with:
API support for immediate group deletion
You can now use the API to immediately delete individual subgroups. Prior to this release, you could only delete individual subgroups from group settings in the UI.
See Documentation and Issue.
Related
Is it possible to hide:
board names in dropdowns in the Boards menu
folder name is the Pipelines menu
the Project settings page
from users of a given user group in Azure DevOps?
Boards menu dropdown
Pipelines menu folders
I can hide the pipelines and work items but not the pipeline folders and board names in the dropdowns.
I added one user in the readers group to access the Azure DevOps project, the user was able to view the boards and the Work items like below but was unable to edit it due to reader role :-
Now, I visited the Project Settings with my Admin Account > Boards > Team configuration > Areas > Security > View work items in this node > Deny
Now, When I route back to my user who's added to Readers group > The Work Items in Boards are not visible like below:-
To Deny access to Pipelines, Refer the following setting below:-
Go to Pipelines > three dots > Manage security> Deny > View Build pipeline and View builds like below:-
The Pipeline folder is not visible to the user like below:-
References:-
permissions - Azure DevOps deny access to Pipelines - Stack Overflow by Shamrai Aleksander
How to restrict work item visibility/access to the team only in Azure DevOps | by Zaniar | Medium By zaniar
I have created a release pipeline with multiple stages. Now I would like on users form the Release Manager group or Project Administrators group to be able to deploy some of these stages.
I have tried to denied "Manage Deployments" to the other groups but it seems as soon as Contributors lose this, no one, not even members of the above groups with the permission set to Allow can deploy the stage anymore. BTW, members of the allowed groups are also members of Contributors.
I tried both just updating the permission and removing Inherited permissions and then removing the permission for those groups and still no go.
Is there any way to remove this permission from Contributors but sill allow members of Contributors + Release Manager + Project Managers to deploy?
Thank you
Is there any way to remove this permission from Contributors but sill allow members of Contributors + Release Manager + Project Managers to deploy?
I could reproduce the scene you mentioned. It seems that the permissions of the Contributors group will override the permissions of the other two groups.
To solve this issue, you could set the Manage Deployments as Not Set instead of Deny. At the same time, you need the disable Inheritance option.
Note: If you set Not Set, people in the contributor group cannot deploy, but if some of them are in other groups with this permission, they will inherit the permissions from other groups
I have a Gitlab group (testgroup) also I have the project (testproject). Now the testproject is in the testgroup.
What would happen if I added A group (testgroup) master as a developer in the inside of the project?
Would they able to accept the merge request for the particular project?
How could I add the group master as a developer in the same group's project?
Someone who is declared a group master is not a project Master, even if that project is in the group
See Group permission: he or she only has the additional privilege of creating projects in the group.
I'm trying to import work items from TFS to VSTS. I have some work items that are assigned to a group that won't import. I recreated the group in VSTS, but when I try to import excel gives me an error:
The identity value 'TriageGroup' for field 'AssignedTo' is an unknown identity.
Triage group is not an AD group which is why VSTS can't assign to it, but it never was in the old TFS world either. Any ideas? Is it possible to import WIs assigned to a group?
There should be some customization made for the WIT Definition in your TFS server what allow the group to be assigned for Work Items. But for VSTS, there isn't any way to customize the WIT definition for now. That means you cannot assign the work item to group in VSTS. You can only assign the work item to an valid user.
When I try to create a new Azure Redis Cache and choose a location I just get a "There are no locations available." message.1 Setting everything else first still results in the same error. Refreshing the page doesn't resolve the issue. The problem occurs in both IE and Chrome.
Thanks for reporting this. It seems to be a bug in the portal. I can reproduce it if I click "Location" immediately after the "New Redis Cache" blade opens. However, if I wait a few seconds before clicking "Location", it doesn't repro.
As a workaround, if you close and reopen the "Location" blade it should populate correctly.
We will also work on fixing this in the portal.
Finally, for any issues with Azure Redis Cache you can contact us via email at azurecache#microsoft.com.
After working with the Azure team via email we were able to narrow down the problem and find a workaround.
There are 3 problems at work here that result in my symptoms:
The various New blades in the portal will default you to a disabled subscription. I believe they currently default to the first subscription (oldest) which may not be an active subscription. This results in the default behavior upon choosing a blade to be that of no-subscription.
The New Redis Cache blade will only show locations if you have selected a valid (not disabled) subscription. This behavior differs from the other New blades (such as Create VM) which will show you locations even if you have a disabled subscription selected.
Changing the resource group will automatically change the subscription and lock it, but changing the subscription in this way will not trigger an update to the blade. This means that the locations don't get updated for the new subscription because the subscription-changed-event (made up name) was not fired. In my case, I was always changing the subscription by way of changing the resource group, so I was never able to set the location.
The workaround:
Simply change to an active subscription before choosing a resource group. This will cause the locations list to be updated, and you can then choose a resource group after.