nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Before renaming or deleting a Jira group, what proof do you require?

Jonas Nilsson _ Unitlane

When you are about to rename or delete a Jira group, what do you personally need to see before you are comfortable making the change?

In a lot of environments, the click itself is easy. The harder part is proving where the group still matters across project roles, permission schemes, and inherited access before someone owns the risk.

I am building around that exact review step here:

https://unitlane.net/products/group-impact-audit-jira/

Curious what other admins treat as the minimum safe review bar.

Comments

Becker_ Rene

Hi @Jonas Nilsson _ Unitlane :

Actually it's very easy for us.

We have designated groups. For example:
- Group for obtaining a Confluence License

- Group for being allowed everything that is not restricted

- Group per Space (if neccessary) with extended permissions

These groups work additive.

One may argue that this is a lot of work but in fact, once all has been set up intially, it's not much to do (to be fair, we are not an agile company with some 1500 users).

---

So, unless the group was used wrong, we can determine by its name, where it is supposed to be used.

We can then check if its in use for permissions.

If it used somewhere, where it wasn't supposed to be used -> Scream Test (also beneficial to find blind spots).

Hope it helps

---

Jonas Nilsson _ Unitlane

Thanks, that helps.

A clean designated-group model like that definitely removes a lot of ambiguity up front.

The part I still find interesting is that naming tells you intended use, but not necessarily every actual dependency that may have built up over time, especially once permissions are additive.

That is also why the scream test stands out to me. It works, but it also suggests there is still some uncertainty in the review step, otherwise you would not need it.

So I can see why this feels manageable in a structured environment, but I still think the harder cases start when intended use and actual use drift apart.

Becker_ Rene

I agree.

Let me allow to explain a bit more, to show how it works:

Group scheme

Group 1: confluence_license

Group 2: confluence_default_write

Group 3: confluence_spacekey1_internal

Group 4: confluence_spacekey1_admin

Group 5: confluence_spacekey1_whatever

So you see, Group 3-5 is 100% only designated to 1 space.

Administrative side (actual admins):

If the group is used anywhere but the correct space, it can only be a mistake (=> scream test to find them). Since only experienced Confluence admins assign these groups, the likelyhood of a mistake is very small (almost null).

Also groups can only be filled/emptied by admins.

Except for Group 1 and 2, there are no groups like "write in spacekey1 AND spacekey2".

Also, there are no role groups that cover more than 1 space or funtion, role, ... .

=> We rather have a user with 200 Confluence groups, than 1 group that covers multiple functions.

=> in reality whe have some 50 groups (1.400 users)

The key to keep this concept managable lies in group 2.

- (Almost) Every space has a permission entry for group 2 (space level).

- Almost all spaces, do not have a hidden area (group 3).

=> heavily used standard permissions, only edge cases use designated groups.

------

Furthermore, below hierarchy level 1 (below "start page" of a space), people are on their own, (direct assignments) except they explicitly request a group. We only help, if they mess up. I never saw a case, where they used the administrative groups . If they did -> Scream test

Some of the magic is in how Confluence has a bad group search. You'd have to exactly know the name of a group, because half-fuzzy search does not work for strings that have no spaces.

Example

1) prefix_spacekey1-internalArea => hard to find, if you search for "spacekey1"

2) Spacekey1 InternalArea => fuzzy search will pick it up easily

So: never ever remove group 2 in the directory, the rest is fine/transparent.

===

User side:

Use direct permission assignments on single pages. => No permission to do it on a space level.

===

You see that the intended use and the actual use have little room to drift. If they do, it's more a training topic bc then users are proactively search for and use your groups.

This system is highly scalable and even allows for denial permissions (=do not grant).

How much work is created by this approach, is determined by the amount of exceptions you allow (or is requested).

----------------

Edit 1:

I can't believe I forgot to mention it :-D

=> If you want to be 100% sure, you can scan your system for group usage by API

I think it's like -> get all spaces (or pages) -> get their permissions -> look for your group.

This approach is heavy on the systems (instance but also your caller) and depending on the size of your instance, may take several days to run.

-----------------------------------------------------

Jonas Nilsson _ Unitlane

Thanks for laying that out.

That is a very tightly governed model, with single-purpose groups, admin-managed membership, and relatively little room for drift. In a setup like that, I agree the review stays much simpler.

The cases I tend to worry about more are the less controlled ones, especially where groups start spanning multiple spaces or projects, legacy permissions linger, or exceptions accumulate over time.

That is where naming shows intended use, but not necessarily every actual dependency, and where the scream test becomes more of a backstop than the proof itself.

Welcome!

It looks like you're new here. Sign in or register to get started.