How to delete Global Permissions Groups and Individual Users
Asked by Markus Raab:

Best explained by the following screenshot.

I have groups and users in my global permissions I want to delete/clean out at all, e.g., "sales" in my screenshot.

I do not see any option to do so? Do you know how to do that?

![image.png](/t5/image/serverpage/image-id/15118iBD44006BD147A99E/image-size/large?v=v2&px=999 "image.png")


Answers:
author: Shannon S
body: Hello again, Markus!

Testing in 6.7.0, when you uncheck **can use** and click **Save all** at the bottom, the users and groups are removed from Global Permissions.

If this wasn't working for you, as I see it's what you're attempting to do, can you let me know what version of Confluence you are on?

Shannon

comments: author: Markus Raab
body: I know that this method works for other permissions (e.g., in a space). But it does not work here ...

Confluence Server 6.2.4


author: Shannon S
body: Hi Markus,

Actually, I did test it in Global Permissions and confirmed it works in 6.7.0.

I just tested this as well in 6.2.4, and I'm also able to get it to work there.

To make sure I'm not misinterpreting your request, could you have a look at this video I made?

<https://screencast-o-matic.com/watch/cFnD01oM0p>

This is how I understand what you're trying to do, so let me know if I have misunderstood.

Regards,

Shannon


author: Markus Raab
body: Now it works!

I had to re-check them first (they all have been already un-checked) - hit save - edit again and uncheck them and save again. Vollay.

Thanks for your work and support!

Obviously the problem was connected to settings from a previous version.

best

Markus


author: Shannon S
body: Markus,

Ah! That's a good catch; I hadn't realized they were unchecked already. I saw this before, now that you mention it, and re-checking/unchecking is what ultimately resolved it. I agree that it was probably a bug from before.

I tried to search through jira.atlassian.com for a bug that might have caused this, but I was unfortunately not able to find any reported bugs for us to know what version might have caused that.

Regards,  
Shannon


author: Markus Raab
body: Thanks Shannon!


author: Geno Spain
body: This solution does not work on the cloud.


author: Shannon S
body: Geno,

This question was related specifically to Confluence Server.

If you have the same question for Cloud, I would recommend that you raise a new question in the Confluence Cloud question and someone will be able to help you out.

Regards,

Shannon


author: Jan
body: [@Shannon](/t5/user/viewprofilepage/user-id/2531634)

We do have this issue too, I know that re-checking, unchecking and saving would clear the list, but it is several hundred entries in our case (single users). And I do not know, how all users got in the list at all. Is there a way to bulk remove them?


author: Shannon S
body: Jan,

There might be a way using the API, so I would recommend [reviewing the documentation on that](https://developer.atlassian.com/server/confluence/confluence-permissions-architecture/).

Otherwise, please have a look at the marketplace add-ons for Permissions, perhaps one will be able to help you accomplish this.

* [Confluence Permissions Add-ons in Marketplace](https://marketplace.atlassian.com/search?product=confluence&query=permissions)

Regards,

Shannon


author: Jan
body: It would be nice if Atlassian could have a look at this. As entries (lines) in all other permission dialogues are removed by unchecking all, I do not understand why hundreds of lines wihtout any checked permissions are shown in the global permissions and there is no other way for getting rid of them than manually setting permissions to remove them again. I hope you understand what I mean.

Especially as we never added these lines to the global permissions (single users) as we only set global permissions with groups.

The huge list in there even causes timeouts when loading sometimes.


author: Shannon S
body: Jan,

I would recommend raising this as a feature request, which you can do from [jira.atlassian.com](https://jira.atlassian.com/secure/CreateIssue!default.jspa).

I had a look earlier and I didn't see anything that I really thought applied, so please feel free to do so.

Regards,

Shannon


author: Marion Hederer
body: Hi Jan,

could you tell me how you resolved this issue? I'm facing exactly the same Problem and don't even know who users got in this list.


author: its moi
body: [@Marion Hederer](/t5/user/viewprofilepage/user-id/1761957) has not really been fixed yet and seems like there is some kind code in Confluence causing this in combination with a 3rd party plugin; we are still in contact with Atlassian support re. this


author: Marion Hederer
body: [@its moi](/t5/user/viewprofilepage/user-id/3830004)do you know what 3rd Party Plugin?


author: its moi
body: [@Marion Hederer](/t5/user/viewprofilepage/user-id/1761957) it is most likely one of Linchpin Intranet Suites Addons


author: Martin Seibert
body: Feel free to raise a support ticket with our [Linchpin](https://www.linchpin-intranet.com/) technical team here: <https://seibert.biz/help>


author: Annabell Langs
body: Hi,

we are facing the same problem similarly without an understanding how the users got into the list. In fact we have Linchpin Enterprise News and Mail Page - so if indeed this is an issue with one of the Linchpin Intranet Suites Addons as mentioned by [@its moi](/t5/user/viewprofilepage/user-id/3830004), then it is likely the News addon (or one of its Linchpin dependencies).

Best regards


author: Martin Seibert
body: Pinged our team again. But as above: Feel free to raise a support ticket with our [Linchpin](https://www.linchpin-intranet.com/) technical team here: <https://seibert.biz/help>


author: Christopher ?lm?ller
body: Hi Annabell,

I can try to shed some light on how those mysterious entries came to exist. Most of our findings have since been included by Atlassian in the corresponding **[Confluence knowledge base article](https://confluence.atlassian.com/confkb/how-to-remove-corrupted-space-permissions-appearing-in-the-global-permissions-page-956159753.html)**, so I'll sum those up here:

* There's an issue with the currently recommended Confluence API to remove space permissions, which instead of removing them will set their associated space key to NULL. Unfortunately, permissions with space=NULL are treated as global in a special way, so the *Global permissions* screen tries to display them (this is the all-red entries you're seeing)
* Those permissions will thus show up as "global", but of course they are not mapped to actual global permissions, since they're still configured on a space-level (so they would control e.g. EDITSPACE or REMOVECOMMENT permissions, which are not valid on a global level). So what's being displayed in the global permissions are space-based permissions that are lacking their space identifier, but that don't apply to the Confluence-global level.
* Confluence apps are likely to use the affected API method if they're looking for this functionality, since the replacement method (which in our testing behaved as expected and didn't cause the problem observed here) is marked as deprecated. The only solution to prevent generating more such entries currently is to use the deprecated method, which Atlassian have marked as *safe to use them until replacement methods are available in the future.*
* For [**Linchpin Enterprise News**](https://marketplace.atlassian.com/apps/1215396/linchpin-enterprise-news), once we had worked out the internal data relationships and coordinated with Atlassian, we released patches that switch our app code to using the deprecated method. This ensures that after installing the patch, News operations will correctly handle the associated workflow-space permissions. It unfortunately cannot retroactively check existing permissions and "repair" them.
* To clean up the orphaned generated before installing the Enterprise News patch, we recommend handling this on database level (follow the **Diagnosis** \& **Resolution** steps in the [knowledge base article](https://confluence.atlassian.com/confkb/how-to-remove-corrupted-space-permissions-appearing-in-the-global-permissions-page-956159753.html) for instructions). This consists of determining which "global" permissions don't make sense in the current state since they're not of any global permission type, and removing them if so.

In short, faulty permissions were generated by the Confluence API and are accidentally displayed as global permissions. With **Linchpin Enterprise News 2.12.2** (released early July) and higher, such permissions are no longer generated, but existing data will remain in the system until cleaned up. The easiest way of cleaning up is removing the affected database entries.

If you're aware of other plugins managing a space permission reset in some way, make sure to forward them the KB article. Or if you're reading this and develop Confluence plugins yourself, please check the [**Note for plugin developers**](https://confluence.atlassian.com/confkb/how-to-remove-corrupted-space-permissions-appearing-in-the-global-permissions-page-956159753.html#HowtoremovecorruptedspacepermissionsappearingintheGlobalPermissionspage-Noteforplugindevelopers.1) section to avoid running into the same problem!

Hope that helped a bit! In general, like Martin mentioned above: Feel free to reach out to our support team (<https://seibert.biz/help>) for any questions that come up when using Linchpin :)

Best regards,  
Chris


author: Annabell Langs
body: Thanks for the detailed reply! We will try to follow your advice with installing the latest version of the app and removing the entries as hinted by the KB article. As a developer myself I appreciate your details on the implementation side helping out other developers with this issue.