How to delete Global Permissions Groups and Individual Users

Markus Raab February 16, 2018

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

 

1 answer

1 accepted

0 votes
Answer accepted
Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 16, 2018

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

Markus Raab February 16, 2018

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

Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 16, 2018

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

Like Svenja Lorenzen likes this
Markus Raab February 16, 2018

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

Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 16, 2018

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

Markus Raab February 17, 2018

Thanks Shannon!

Geno Spain November 14, 2018

This solution does not work on the cloud.  

Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 14, 2018

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

Jan January 31, 2019

@Shannon

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? 

Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 1, 2019

Jan,

There might be a way using the API, so I would recommend reviewing the documentation on that.

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

Regards,

Shannon

Jan February 1, 2019

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. 

Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 1, 2019

Jan,

I would recommend raising this as a feature request, which you can do from jira.atlassian.com.

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

Marion Hederer June 18, 2020

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. 

its moi June 18, 2020

@Marion Hederer 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

Like Marion Hederer likes this
Marion Hederer June 19, 2020

@its moido you know what 3rd Party Plugin? 

its moi June 24, 2020

@Marion Hederer it is most likely one of Linchpin Intranet Suites Addons 

Martin Seibert
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 24, 2020

Feel free to raise a support ticket with our Linchpin technical team here: https://seibert.biz/help

Annabell Langs September 7, 2020

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, then it is likely the News addon (or one of its Linchpin dependencies).

Best regards

Martin Seibert
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 7, 2020

Pinged our team again. But as above: Feel free to raise a support ticket with our Linchpin technical team here: https://seibert.biz/help

Christopher Ölmüller September 9, 2020

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, 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, 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 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 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

Like # people like this
Annabell Langs September 10, 2020

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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events